This reverts commit b7a036a6.

Reason for revert: We don't want to ever access the heap when walking the stack

Original change's description:
> [frames] Make interpreted frame detection stricter (reland)
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a valid pointer to a BytecodeArray.
> 
> Reland of https://chromium-review.googlesource.com/c/535646/
> 
> Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
> Reviewed-on: https://chromium-review.googlesource.com/536935
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45959}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: I52a62c8e11af4d1565af92f10113b955f8c2c2f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/536938Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45960}

When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a valid pointer to a BytecodeArray.

Reland of https://chromium-review.googlesource.com/c/535646/

Change-Id: Iefbf305c9e4b43bebd2fc111663671d2b675e64a
Reviewed-on: https://chromium-review.googlesource.com/536935Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45959}

This reverts commit f577b2bb.

Reason for revert: Failure on https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20verify%20csa/builds/1978

Original change's description:
> [frames] Make interpreted frame detection stricter
> 
> When iterating over stack frames, make the interpreted frame detection
> require that the frame header contains the bytecode array.
> 
> Currently, the stack frame iterator supports bytecode handlers that
> don't create stack frames by checking if the top of the stack (i.e. the
> return address) is the interpreter entry trampoline. However, optimized
> code tail called from the interpreter entry trampoline can move the
> stack pointer without clearing the stack, which means it can end up with
> a pointer into the interpreter entry trampoline on the top of its stack
> (in an uninitialized value), and be interpreted as an interpreted frame.
> 
> To avoid such optimized code frames being interpreted as interpreted
> frames, we now additionally test the frame header, to see if it contains
> a BytecodeArray.
> 
> Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
> Reviewed-on: https://chromium-review.googlesource.com/535646
> Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45951}

TBR=kozyatinskiy@chromium.org,leszeks@chromium.org

Change-Id: Icc009cf97b816f6c33574782ed9ab473387886c9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/535478Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45954}

When iterating over stack frames, make the interpreted frame detection
require that the frame header contains the bytecode array.

Currently, the stack frame iterator supports bytecode handlers that
don't create stack frames by checking if the top of the stack (i.e. the
return address) is the interpreter entry trampoline. However, optimized
code tail called from the interpreter entry trampoline can move the
stack pointer without clearing the stack, which means it can end up with
a pointer into the interpreter entry trampoline on the top of its stack
(in an uninitialized value), and be interpreted as an interpreted frame.

To avoid such optimized code frames being interpreted as interpreted
frames, we now additionally test the frame header, to see if it contains
a BytecodeArray.

Change-Id: I4bafcf0f7ce3c973a2e5a312f054d72312bb8a70
Reviewed-on: https://chromium-review.googlesource.com/535646Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45951}

This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.

R=jarin@chromium.org
BUG=v8:6409

Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}

This CL contains a few pieces:

- A new mechanism to create "BuiltinContinuation" checkpoints in TurboFan
  graphs, which--when triggered--swizzle the values in the the FrameState to be
  parameters to a typically TF-generated builtin that resumes execution to finish
  the slow-case functionality.
- Continuation builtins that have special handling in the deoptimizer and their own
  new frame type to ensure that the values they need to begin executing can be stashed
  away and restored immediately before the builtin is called via a trampoline that runs
  when the continuation builtin's frame execution resumes.
- An implementation of Array.prototype.forEach in TurboFan that can be used to
  inline it. The inlined forEach implementation uses the checkpoints mechanism
  described above to deopt in the middle of the forEach in the cases that optimization
  invariants are violated. There is a slightly different continuation stub for each
  deopt point in the forEach implementation to ensure the correct side-effects, i.e.
  that the deopt of the builtin isn't programmatically observable.

Review-Url: https://codereview.chromium.org/2803853005
Cr-Commit-Position: refs/heads/master@{#45764}

Change-Id: I20ed35a7fb5104a9cc66bb54fa8966589c43d7f9
Reviewed-on: https://chromium-review.googlesource.com/507287Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Jochen Eisinger <jochen@chromium.org>
Commit-Queue: Wiktor Garbacz <wiktorg@google.com>
Cr-Commit-Position: refs/heads/master@{#45458}

This patch adds a new interface called RootVisitor and changes the root
iteration functions to accept a RootVisitor instead of an ObjectVisitor.

Future CLs will change ObjectVisitor to provide the host object to all
visiting functions, which will bring it in sync with static visitors.

Having separate visitors for roots and objects removes ambiguity in
VisitPointers and reduces chances of forgetting to record slots.

This is intended as pure refactoring. All places that require behavior
change are marked with TODO and will addressed in future CLs.

BUG=chromium:709075

Review-Url: https://codereview.chromium.org/2801073006
Cr-Commit-Position: refs/heads/master@{#44852}

This CL implements the proposed change to show information about
WebAssembly values and call frames via the inspector interface.
Each interpreted WebAssembly frame will have two scopes: A global scope
showing information about the memory (to be extended for globals), and
a local scope showing information about parameters, local variables, and
stack values.
Names of local variables will be added later.

R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:6245,v8:5822

Change-Id: I0a35fddd0a353933c86adf62083233b08098a2c7
Reviewed-on: https://chromium-review.googlesource.com/474865
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44633}

InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I83e2f096782db685fe316dd071980cd8d696fe53
Reviewed-on: https://chromium-review.googlesource.com/469927Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44483}

This reverts commit 9461fe24.

Reason for revert: Breaks a test in Node.js: 
 parallel/test-util-inspect

=== release test-util-inspect ===                                              
Path: parallel/test-util-inspect
#
# Fatal error in , line 0
# unreachable code
#

==== C stack trace ===============================


Original change's description:
> [builtins] don't inline calls for common Promise ops in async builtins
> 
> InternalResolvePromise, InternalPromiseReject and
> InternalPerformPromiseThen generate quite a lot of code.
> 
> This change adds 3 new TF stubs which inline calls to these builtins.
> These stubs are invoked rather than inlining those operations listed
> above directly. This is done for Async Iteration builtins, as well as
> Async Function builtins. Promise builtins are left as they were, and
> continue to inline these calls.
> 
> This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
> release build.
> 
> BUG=v8:5855
> R=​gsathya@chromium.org, jgruber@chromium.org
> 
> Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
> Reviewed-on: https://chromium-review.googlesource.com/461269
> Commit-Queue: Caitlin Potter <caitp@igalia.com>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#44445}

TBR=mstarzinger@chromium.org,gsathya@chromium.org,caitp@igalia.com,jgruber@chromium.org,v8-reviews@googlegroups.com,bmeurer@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5855

Change-Id: Iabcdf8b025cc9b053a858f8e74389638ac000ba0
Reviewed-on: https://chromium-review.googlesource.com/469946Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Franziska Hinkelmann <franzih@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44448}

InternalResolvePromise, InternalPromiseReject and
InternalPerformPromiseThen generate quite a lot of code.

This change adds 3 new TF stubs which inline calls to these builtins.
These stubs are invoked rather than inlining those operations listed
above directly. This is done for Async Iteration builtins, as well as
Async Function builtins. Promise builtins are left as they were, and
continue to inline these calls.

This results in a roughly 99kb reduction in snapshot_blob.bin on an x64
release build.

BUG=v8:5855
R=gsathya@chromium.org, jgruber@chromium.org

Change-Id: I3349d0f0353a72270ae40b974312d64d1c8a9e46
Reviewed-on: https://chromium-review.googlesource.com/461269
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran (ooo until April 10) <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44445}

The WasmCompileLazy builtin creates an internal frame, thus the garbage
collector will visit all pointers in the stack frame.
However, we will call this builtin from compiled wasm code, and it
receives raw (untagged) arguments. This is because this builtin is
later exchanged by compiled wasm code, so the ABI needs to be
compatible.

This CL introduces the has_tagged_params code flag, which is true by
default and false for each WASM_FUNCTION, JS_TO_WASM_FUNCTION and
the WasmCompileLazy builtin.
The gargabe collector just ignores the parameters for each frame
whose code object has this flag set to false. For internal frames,
all pointers in the whole stack frame are ignored if the flag is set.

R=titzer@chromium.org, mstarzinger@chromium.org
BUG=v8:5991

Change-Id: I12a15157db344725bcc280e2041fd5bcad2ba700
Reviewed-on: https://chromium-review.googlesource.com/451400
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43884}

Use an opaque format for the frame type marker on the stack, where the
marker is simply shifted left by 1 instead of being a Smi. This allows
us to generate simpler code for frame initialisation, as we can push a
smaller value, decreasing the prologue by 4 bytes and one instruction.

Drive-by: Use the same format for JsFrameMarker.

Change-Id: I812dde9b37869fe20de4148a665d06cf23ce7372
Reviewed-on: https://chromium-review.googlesource.com/443426Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43347}

Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.

For example, consider the program

function inner() {
  var s = 0;
  for (var i = 0; i < 100000; i++) {
    s += i * i;
  }
  return s;
}

function trivial() {
  return inner();
}

for (var i = 0; i < 2000; i++) {
  trivial();
}

Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:

  [JavaScript]:
   ticks  total  nonlib   name
   4885   83.4%   83.5%  Function: ~trivial a.js:15:17
    759   13.0%   13.0%  Function: ~inner a.js:7:15

After this change, we get

 [JavaScript]:
   ticks  total  nonlib   name
   5486   95.9%   96.2%  Function: ~inner a.js:7:15
      4    0.1%    0.1%  Function: ~trivial a.js:15:17

Review-Url: https://codereview.chromium.org/2667253004
Cr-Original-Commit-Position: refs/heads/master@{#42894}
Committed: https://chromium.googlesource.com/v8/v8/+/d07f6540c1f9628ed2ba1fa6507c90db07ccc5f5
Review-Url: https://codereview.chromium.org/2667253004
Cr-Commit-Position: refs/heads/master@{#42924}

Revert of [profiler] Fix attribution for the top-most interpreted frame. (patchset #3 id:40001 of https://codereview.chromium.org/2667253004/ )

Reason for revert:
Flaky crashes on mac asan:
https://build.chromium.org/p/client.v8/builders/V8%20Mac64%20ASAN/builds/10739

Original issue's description:
> [profiler] Fix attribution for the top-most interpreted frame.
>
> Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.
>
> For example, consider the program
>
> function inner() {
>   var s = 0;
>   for (var i = 0; i < 100000; i++) {
>     s += i * i;
>   }
>   return s;
> }
>
> function trivial() {
>   return inner();
> }
>
> for (var i = 0; i < 2000; i++) {
>   trivial();
> }
>
>
> Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:
>
>   [JavaScript]:
>    ticks  total  nonlib   name
>    4885   83.4%   83.5%  Function: ~trivial a.js:15:17
>     759   13.0%   13.0%  Function: ~inner a.js:7:15
>
> After this change, we get
>
>  [JavaScript]:
>    ticks  total  nonlib   name
>    5486   95.9%   96.2%  Function: ~inner a.js:7:15
>       4    0.1%    0.1%  Function: ~trivial a.js:15:17
>
> Review-Url: https://codereview.chromium.org/2667253004
> Cr-Commit-Position: refs/heads/master@{#42894}
> Committed: https://chromium.googlesource.com/v8/v8/+/d07f6540c1f9628ed2ba1fa6507c90db07ccc5f5

TBR=bmeurer@chromium.org,jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2670843005
Cr-Commit-Position: refs/heads/master@{#42912}

Before this change, we attributed samples for the top-most interpreter frame to the second-topmost frame if we were in a bytecode handler with elided frame. With this change we try to detect that we are in a handler without a frame. If we are, we do not drop the topmost frame.

For example, consider the program

function inner() {
  var s = 0;
  for (var i = 0; i < 100000; i++) {
    s += i * i;
  }
  return s;
}

function trivial() {
  return inner();
}

for (var i = 0; i < 2000; i++) {
  trivial();
}

Before this change, d8 --prof --ignition --nocrankshaft and linux-tick-processor would produce:

  [JavaScript]:
   ticks  total  nonlib   name
   4885   83.4%   83.5%  Function: ~trivial a.js:15:17
    759   13.0%   13.0%  Function: ~inner a.js:7:15

After this change, we get

 [JavaScript]:
   ticks  total  nonlib   name
   5486   95.9%   96.2%  Function: ~inner a.js:7:15
      4    0.1%    0.1%  Function: ~trivial a.js:15:17

Review-Url: https://codereview.chromium.org/2667253004
Cr-Commit-Position: refs/heads/master@{#42894}

- Remove obsolete BreakLocatorType.
- Perform PrepareStepOnThrow after OnException event, in case stepping
  was scheduled in the exception event.
- Use frame count instead of frame pointer for stepping. Frame pointer
  is not reliable due to possible deopts.
- Consistently check for inlined functions in inlined frames.
- Use SharedFunctionInfo in FloodWithOneshot and EnsureDebugInfo.

R=jgruber@chromium.org
BUG=v8:5901

Review-Url: https://codereview.chromium.org/2664793002
Cr-Commit-Position: refs/heads/master@{#42878}

Implement stepping by remembering the current step action in the wasm
interpreter handle in WasmDebugInfo, and using it when continuing
execution in the interpreter.
The control flow is as follows: After module compilation, the user sets
a breakpoint in wasm. The respective function is redirected to the
interpreter and the breakpoint is set on the interpreter. When it is
hit, we notify all debug event listeners, which might prepare stepping.
When returning from these listeners, before continuing execution, we
check whether stepping was requested and continue execution in the
interpreter accordingly.

Stepping from Wasm to JS and vice versa will be implemented and tested
in a follow-up CL. Testing this requires breakpoints and stepping in
Wasm to be exposed via the inspector interface, such that we can write
an inspector test. This mixed JS-Wasm-execution is hard to set up in a
cctest.

R=titzer@chromium.org, yangguo@chromium.org
BUG=

Review-Url: https://codereview.chromium.org/2649533002
Cr-Commit-Position: refs/heads/master@{#42624}

Frame inspection is currently limited to locations of execution.
Further details like local variables or stack content will follow later.

The FrameInspector now stores a pointer to the interpreted wasm frame,
and redirects certain requests there, just as for deoptimized frames.
Hitting breakpoints is now also supported for wasm frames.

R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2629823003
Cr-Commit-Position: refs/heads/master@{#42551}

Document that frame summaries are bottom-to-top, i.e. caller before
callee, rename FrameSummary::GetFirst to FrameSummary::GetBottom and
introduce FrameSummary::GetTop.
For debugged JavaScript frames, it does not really matter which of the
functions we call, so I replaced a few GetFirst by GetTop instead of
GetBottom because it matches the semantics more closely.

This CL also reverts part of http://crrev.com/2621953002 by changing
BreakLocation::FromFrame back to accept a DebugInfo and a
JavaScriptFrame. We don't plan to create BreakLocations for wasm.

R=yangguo@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2647433002
Cr-Commit-Position: refs/heads/master@{#42505}

This adapts the aformentioned interface to no longer return a list of
{JSFunction} objects, but {SharedFunctionInfo} objects instead. Since
deoptimization data only contains the latter as literals, this by now
represents the fast path. All call sites requiring the former can use
the slow path via {JavaScriptFrame::Summarize} instead.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2626213002
Cr-Original-Commit-Position: refs/heads/master@{#42311}
Committed: https://chromium.googlesource.com/v8/v8/+/25a9364f25a40986f4d7266b1fe53a5921754f6a
Review-Url: https://codereview.chromium.org/2626213002
Cr-Commit-Position: refs/heads/master@{#42314}

Revert of [runtime] Change JavaScriptFrame::GetFunctions interface. (patchset #2 id:20001 of https://codereview.chromium.org/2626213002/ )

Reason for revert:
Breaks compilation.

Original issue's description:
> [runtime] Change JavaScriptFrame::GetFunctions interface.
>
> This adapts the aformentioned interface to no longer return a list of
> {JSFunction} objects, but {SharedFunctionInfo} objects instead. Since
> deoptimization data only contains the latter as literals, this by now
> represents the fast path. All call sites requiring the former can use
> the slow path via {JavaScriptFrame::Summarize} instead.
>
> R=jarin@chromium.org
>
> Review-Url: https://codereview.chromium.org/2626213002
> Cr-Commit-Position: refs/heads/master@{#42311}
> Committed: https://chromium.googlesource.com/v8/v8/+/25a9364f25a40986f4d7266b1fe53a5921754f6a

TBR=jarin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true

Review-Url: https://codereview.chromium.org/2629113004
Cr-Commit-Position: refs/heads/master@{#42312}

This adapts the aformentioned interface to no longer return a list of
{JSFunction} objects, but {SharedFunctionInfo} objects instead. Since
deoptimization data only contains the latter as literals, this by now
represents the fast path. All call sites requiring the former can use
the slow path via {JavaScriptFrame::Summarize} instead.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2626213002
Cr-Commit-Position: refs/heads/master@{#42311}

Wasm frames can be either compiled or interpreted. For interpreted wasm
frames, there is only one physical stack frame representing an
arbitrary stack of interpreted functions. Hence the physical stack
frame needs to provide a summary of the underlying functions.
Summaries were tailored for JavaScript frames before. Now they are
universal.

The refactored FrameSummaries are now also used in the FrameInspector,
and from the StackFrame objects themselves, to avoid code duplication.

All dispatch is implemented "manually", making the FrameSummary still
stack-allocatable.

BUG=v8:5822
R=yangguo@chromium.org, titzer@chromium.org

Review-Url: https://codereview.chromium.org/2619353006
Cr-Commit-Position: refs/heads/master@{#42279}

and rename WasmFrame to WasmCompiledFrame.
The WasmToInterpreterFrames are not used yet; this will follow in a
follow-up CL (see tracking bug for the overall picture).
Those frames will represent frames for WASM_TO_INTERPRETER stubs, which
call from wasm code to the wasm interpreter, implemented in C++.
They will support the Summarize method to inspect the stack frames in
the wasm interpreter.

R=yangguo@chromium.org, titzer@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2623773004
Cr-Commit-Position: refs/heads/master@{#42213}

BUG=v8:5620
R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2620973002
Cr-Commit-Position: refs/heads/master@{#42172}

The new object will hold information which is shared by all clones of a
WasmCompiledModule, e.g. the decoded asm.js offset table, and in the
future also breakpoints. From there, we can set them on each new
instantiation of any clone.

While already changing lots of the code base, I also renamed all
getters from "get_foo" to "foo", to conform to the style guide.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5732

Review-Url: https://codereview.chromium.org/2591653002
Cr-Commit-Position: refs/heads/master@{#41862}

Plus another minor refactoring.

R=titzer@chromium.org

Review-Url: https://codereview.chromium.org/2590563002
Cr-Commit-Position: refs/heads/master@{#41853}

When executing wasm code for testing, we did not create a
WasmInstanceObject and link it to the generated code. This required
some special handling at runtime (mainly for stack trace generation).
This CL always provides the WasmInstanceObject, such that e.g. function
names can be resolved the usual way.
The module bytes referenced by the WasmCompiledModule linked with the
WasmInstanceObject do not hold a valid wasm module yet. Instead, we
just add the bytes we need, and make the objects in WasmModule point to
those bytes (currently only used for function names). Those bytes will
not be parsed at runtime anyway.

R=titzer@chromium.org
CC=jgruber@chromium.org
BUG=v8:5620

Review-Url: https://codereview.chromium.org/2551053002
Cr-Commit-Position: refs/heads/master@{#41809}

In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- the StackFrame::State struct now also holds the callee_pc_address,
  which is set in ComputeCallerState. The WASM frame uses this
  information to determine whether the callee frame is WASM_TO_JS, and
  whether that frame is at the ToNumber conversion call.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
Review-Url: https://codereview.chromium.org/2555243002
Cr-Original-Commit-Position: refs/heads/master@{#41599}
Cr-Commit-Position: refs/heads/master@{#41613}

Revert of [wasm] Fix location for error in asm.js ToNumber conversion (patchset #5 id:80001 of https://codereview.chromium.org/2555243002/ )

Reason for revert:
gc-stress failures

Original issue's description:
> [wasm] Fix location for error in asm.js ToNumber conversion
>
> In the asm.js code translated to wasm, we call imported functions via a
> WASM_TO_JS stub, which first calls the function and then calls ToNumber
> on the return value. Exceptions can happen in both calls.
> We were only ever reporting the location of the function call, whereas
> asm.js code executed via turbofan reported the location of the type
> coercion operator ("+" on "+foo()" or "|" on "foo()|0").
>
> This CL implements the same behaviour for asm.js code translated to
> wasm. The following is changed:
> - the AsmWasmBuilder records the parent node when descending on a binary
>   operator (also "+foo()" is represented by a binary operation).
> - it stores not one location per call in the source position side
>   table, but two (one for the call, one for the parent which does the
>   type coercion).
> - the wasm compiler annotates the source positions "0" and "1" to the
>   two calls in the WASM_TO_JS wrapper (only if the module origin is
>   asm.js).
> - during stack trace generation (in the StackTraceIterator), when we
>   move from the WASM_TO_JS frame to the WASM frame, we remember at which
>   call inside the WASM_TO_JS wrapper we are, and encode this information
>   in the generated caller state, used for the WASM frame.
> - the same information is also stored in the FrameArray which is used
>   to reconstruct the stack trace later.
>
> R=titzer@chromium.org, bradnelson@chromium.org
> CC=jgruber@chromium.org
> BUG=v8:4203,v8:5724
>
> Committed: https://crrev.com/94cd46b55e24fa2bb7b06b3da4d5ba7f029bc262
> Cr-Commit-Position: refs/heads/master@{#41599}

TBR=bradnelson@chromium.org,mstarzinger@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:4203,v8:5724

Review-Url: https://codereview.chromium.org/2563613003
Cr-Commit-Position: refs/heads/master@{#41601}

In the asm.js code translated to wasm, we call imported functions via a
WASM_TO_JS stub, which first calls the function and then calls ToNumber
on the return value. Exceptions can happen in both calls.
We were only ever reporting the location of the function call, whereas
asm.js code executed via turbofan reported the location of the type
coercion operator ("+" on "+foo()" or "|" on "foo()|0").

This CL implements the same behaviour for asm.js code translated to
wasm. The following is changed:
- the AsmWasmBuilder records the parent node when descending on a binary
  operator (also "+foo()" is represented by a binary operation).
- it stores not one location per call in the source position side
  table, but two (one for the call, one for the parent which does the
  type coercion).
- the wasm compiler annotates the source positions "0" and "1" to the
  two calls in the WASM_TO_JS wrapper (only if the module origin is
  asm.js).
- during stack trace generation (in the StackTraceIterator), when we
  move from the WASM_TO_JS frame to the WASM frame, we remember at which
  call inside the WASM_TO_JS wrapper we are, and encode this information
  in the generated caller state, used for the WASM frame.
- the same information is also stored in the FrameArray which is used
  to reconstruct the stack trace later.

R=titzer@chromium.org, bradnelson@chromium.org
CC=jgruber@chromium.org
BUG=v8:4203,v8:5724

Review-Url: https://codereview.chromium.org/2555243002
Cr-Commit-Position: refs/heads/master@{#41599}

R=bmeurer@chromium.org,titzer@chromium.org

Review-Url: https://codereview.chromium.org/2557693006
Cr-Commit-Position: refs/heads/master@{#41579}

This patch introduces:

1. ICStats class to store ic statistics items produced by V8,
2. A disabled by default tracing category v8.ic_stats,
3. An trace event V8.ICStats that contains ic statistics items in args,

We store ic statistics items in an array until the array is full to reduce
the number of trace events.

TBR=jkummerow@chromium.org,ishell@chromium.org

Review-Url: https://codereview.chromium.org/2503183002
Cr-Commit-Position: refs/heads/master@{#41559}

The range-based exception handler table is by now only used for bytecode
arrays. The semantics of the interpreter are that bytecode offsets point
to the beginning of the currently executing bytecode instruction. Uses
hence need to compensate for lookups based on a "retrun address". This
change removes the need for such off-by-one compensations by changing
lookup semantics to be based on "current instruction" offsets.

R=jarin@chromium.org

Review-Url: https://codereview.chromium.org/2534893002
Cr-Commit-Position: refs/heads/master@{#41339}

Before, the encoded variant was stored in the compiled module, and the
decoded one in the debug info (per instance).
The decoded table was a FixedArray of ByteArrays.
Now, also the decoded table is a flat ByteArray, and it encodes whether
it is encoded or decoded. This saves memory and allows to store encoded
and decoded variant in the same field. The table is automatically
decoded on the first use.

This CL also removes some unused and unimplemented methods from
WasmDebugInfo (probably merge artifacts). That class is now pretty much
empty, but we might still need it for breakpoint support.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2522953002
Cr-Commit-Position: refs/heads/master@{#41316}

This removes support for try-catch as well as try-finally constructs
from the {FullCodeGenerator}. Consequently optimized code containing
such constructs must use the {BytecodeGraphBuilder} and can no longer
use the {AstGraphBuilder} for graph building.

R=jarin@chromium.org
BUG=v8:5657

Review-Url: https://codereview.chromium.org/2521233002
Cr-Commit-Position: refs/heads/master@{#41279}

This removes the deprecated generator support for resumable functions
from {FullCodeGenerator}. The existing {AstNumbering} heuristic already
triggers Ignition for most resumable functions, with this change we make
said heuristic a hard choice and remove the deprecated code. This also
has the advantage that any suspended {JSGeneratorObject} instance on the
heap is guaranteed to have code based on a bytecode array.

R=bmeurer@chromium.org

Review-Url: https://codereview.chromium.org/2504223002
Cr-Commit-Position: refs/heads/master@{#41135}

This makes wasm frames show up nicely in stack traces generated e.g. by
Isolate::PrintStack() and Isolate::PrintCurrentStackTrace().
With this CL, we print the script name, function index, function name,
pc and source position.

R=titzer@chromium.org, ahaas@chromium.org

Review-Url: https://codereview.chromium.org/2509323002
Cr-Commit-Position: refs/heads/master@{#41102}