Refactor call site handling for stack formatting

Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=

Committed: https://crrev.com/f7bc1fc733e9189f67ed16bd492553f2a33de59f
Cr-Commit-Position: refs/heads/master@{#39015}

[jgruber, 2016-08-25 08:06:01]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-25 08:06:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jgruber, 2016-08-25 08:20:30]

jgruber@chromium.org changed reviewers:
+ verwaest@chromium.org

[jgruber, 2016-08-25 08:21:58]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-25 08:22:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-25 09:10:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-25 09:11:10]

Dry run: Try jobs failed on following builders:
  v8_win64_rel_ng on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng/builds/13104)
  v8_win64_rel_ng_triggered on master.tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_win64_rel_ng_triggered/b...)

[jgruber, 2016-08-25 09:25:48]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-25 09:25:52]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-25 09:50:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-25 09:50:06]

Dry run: This issue passed the CQ dry run.

[jgruber, 2016-08-26 11:57:40]

Description was changed from

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* JSCallSite is a new JSObject which contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JSCallSite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

to

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* JSCallSite is a new JSObject which contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JSCallSite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

[jgruber, 2016-08-26 11:57:40]

jgruber@chromium.org changed reviewers:
+ ulan@chromium.org

[jgruber, 2016-08-30 08:33:54]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-30 08:34:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 09:09:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 09:09:40]

Dry run: This issue passed the CQ dry run.

[ulan, 2016-08-30 10:15:56]

Looking good. Two comments:

https://codereview.chromium.org/2275233002/diff/60001/src/builtins/builtins-c...
File src/builtins/builtins-callsite.cc (right):

https://codereview.chromium.org/2275233002/diff/60001/src/builtins/builtins-c...
src/builtins/builtins-callsite.cc:48: CALLSITE_ITER(recv);
We can avoid this macro altogether and replace it with:

FrameArrayIterator it(isolate, GetFrameArray(recv, isolate), GetFrameIndex(recv,
isolate));
return PositiveNumberOrNull(it.Frame()->GetColumnNumber(), isolate);


WDYT?

https://codereview.chromium.org/2275233002/diff/60001/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/2275233002/diff/60001/src/isolate.cc#newcode508
src/isolate.cc:508: // not the case on win64_rel. Find out why.
Are planning to fix it before landing?

[jgruber, 2016-08-30 12:09:24]

The CQ bit was checked by jgruber@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-30 12:09:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jgruber, 2016-08-30 12:11:33]

https://codereview.chromium.org/2275233002/diff/60001/src/builtins/builtins-c...
File src/builtins/builtins-callsite.cc (right):

https://codereview.chromium.org/2275233002/diff/60001/src/builtins/builtins-c...
src/builtins/builtins-callsite.cc:48: CALLSITE_ITER(recv);
On 2016/08/30 10:15:56, ulan wrote:
> We can avoid this macro altogether and replace it with:
> 
> FrameArrayIterator it(isolate, GetFrameArray(recv, isolate),
GetFrameIndex(recv,
> isolate));
> return PositiveNumberOrNull(it.Frame()->GetColumnNumber(), isolate);
> 
> 
> WDYT?

Done.

https://codereview.chromium.org/2275233002/diff/60001/src/isolate.cc
File src/isolate.cc (right):

https://codereview.chromium.org/2275233002/diff/60001/src/isolate.cc#newcode508
src/isolate.cc:508: // not the case on win64_rel. Find out why.
On 2016/08/30 10:15:56, ulan wrote:
> Are planning to fix it before landing?

This was fixed already in https://codereview.chromium.org/2284673002/.
Removed leftover comment.

[jgruber, 2016-08-30 12:12:23]

Description was changed from

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* JSCallSite is a new JSObject which contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JSCallSite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

to

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

[ulan, 2016-08-30 12:14:40]

lgtm

[commit-bot: I haz the power, 2016-08-30 12:42:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-30 12:42:39]

Dry run: This issue passed the CQ dry run.

[jgruber, 2016-08-30 13:25:14]

The CQ bit was checked by jgruber@chromium.org

[commit-bot: I haz the power, 2016-08-30 13:25:22]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-30 13:28:43]

Description was changed from

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

to

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

[commit-bot: I haz the power, 2016-08-30 13:28:45]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-08-30 13:29:16]

Description was changed from

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=
==========

to

==========
Refactor call site handling for stack formatting

This commit introduces several new types:

* JSStackFrame and WasmStackFrame are wrapper classes around a single frame
  in a FrameArray.
* They both inherit from StackFrameBase, which uses virtual dispatch to call
  the correct implementation.
* FrameArrayIterator contains a static instance of JSStackFrame and
  WasmStackFrame and returns a pointer to the corresponding type for each
  frame.
* The JS callsite object now contains the frame array and frame index
  as internal fields.

Internal stack formatting now relies completely on FrameArrayIterator and the
{JS,Wasm}StackFrame types. JS callsite instances are allocated only for custom
user formatting through Error.prepareStackTrace.

BUG=

Committed: https://crrev.com/f7bc1fc733e9189f67ed16bd492553f2a33de59f
Cr-Commit-Position: refs/heads/master@{#39015}
==========

[commit-bot: I haz the power, 2016-08-30 13:29:17]

Patchset 5 (id:??) landed as
https://crrev.com/f7bc1fc733e9189f67ed16bd492553f2a33de59f
Cr-Commit-Position: refs/heads/master@{#39015}