Bug: v8:6514
Change-Id: Ifda1b80a80fc0b077e982005d9493e0fe7ced471
Reviewed-on: https://chromium-review.googlesource.com/599021Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47176}

R=mstarzinger@chromium.org

Bug: 
Change-Id: I95acea7b33a6e5799399d0891b2a52103f5e4964
Reviewed-on: https://chromium-review.googlesource.com/598072Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47116}

Since frames.h no longer defines basic register types like RegList, it
is no longer necessary to include it in the macro assemblers.

Next step: split out frame-constants.h from frames.h so that it will be
possible to get frame constants without include the stackwalking logic,
which needs objects.h.

R=mstarzinger@chromium.org

Bug: 
Change-Id: Ia12d3c8a8d46a73106c3c90bcb4b470c85f1eaa7
Reviewed-on: https://chromium-review.googlesource.com/597788
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47114}

This is a reland of 470a1001
Original change's description:
> Start migration of try/throw/catch to match proposal.
> 
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
> 
> It does the following:
> 
> 1) Use exception tags instead of integers.
> 
> 2) Only handle empty exception signatures (i.e. no values associated
>    with the exception tag.
> 
> 3) Only handle one catch clause.
> 
> 4) Be sure to rethrow the exception if the exception tag does not match.
> 
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
> 
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
> 
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
> 
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}

Bug: v8:6577
Change-Id: I41c3309827c292cb787681a95aaef7cf9b931835
Reviewed-on: https://chromium-review.googlesource.com/598968Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47100}

This reverts commit 470a1001.

Reason for revert: GC stress bot failures.
https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Mac%20GC%20Stress/builds/14522


Original change's description:
> Start migration of try/throw/catch to match proposal.
> 
> This CL does the first baby steps on moving the current (experimental)
> exception handling to match that of the WebAssembly proposal.
> 
> It does the following:
> 
> 1) Use exception tags instead of integers.
> 
> 2) Only handle empty exception signatures (i.e. no values associated
>    with the exception tag.
> 
> 3) Only handle one catch clause.
> 
> 4) Be sure to rethrow the exception if the exception tag does not match.
> 
> Note: There are many things that need to be fixed, and are too
> numerous to list here. However, the code should have TODO's on each
> missing parts of the implementation.
> 
> Also note that the code currently doesn't handle nested catch blocks,
> nor does it change the throw value being an integer. Rather, the
> integer value is still being thrown, and currently is the exception
> tag. Therefore, we don't build an exception object. This is the reason
> why this CL doesn't handle exceptions that pass values.
> 
> Also, the current implementation still can't handle multiple modules
> because tag resolution (between) modules has not be implemented yet.
> 
> Bug: v8:6577
> Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
> Reviewed-on: https://chromium-review.googlesource.com/591910
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47087}

TBR=bradnelson@chromium.org,eholk@chromium.org,kschimpf@chromium.org

Change-Id: I01dc8c40cc1057333a988c1d275ce5f457b0cb64
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6577
Reviewed-on: https://chromium-review.googlesource.com/598847Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47090}

This CL does the first baby steps on moving the current (experimental)
exception handling to match that of the WebAssembly proposal.

It does the following:

1) Use exception tags instead of integers.

2) Only handle empty exception signatures (i.e. no values associated
   with the exception tag.

3) Only handle one catch clause.

4) Be sure to rethrow the exception if the exception tag does not match.

Note: There are many things that need to be fixed, and are too
numerous to list here. However, the code should have TODO's on each
missing parts of the implementation.

Also note that the code currently doesn't handle nested catch blocks,
nor does it change the throw value being an integer. Rather, the
integer value is still being thrown, and currently is the exception
tag. Therefore, we don't build an exception object. This is the reason
why this CL doesn't handle exceptions that pass values.

Also, the current implementation still can't handle multiple modules
because tag resolution (between) modules has not be implemented yet.

Bug: v8:6577
Change-Id: Id6d08b641b3c42d1eec7d4db582f2dab35406114
Reviewed-on: https://chromium-review.googlesource.com/591910Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47087}

This CL refactors the internal representation of JavaScript-exposed
WebAssembly objects to be more like other such objects in V8. By introducing
a new instance type for each of the JS-exposed types, we get more robust
typechecking without using embedder fields (which were previously used
when these objects where instance type JS_API_OBJECT).

In addition to the new instance types, the subclasses X of JSObject
(WasmInstanceObject, WasmMemoryObject, WasmModuleObject, WasmTableObject)
now have appropriate Is##X() methods on Object and are now robust.

BUG=v8:6547
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng

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

- creating JSArray and further setter and getter calls are slower then on fixed array.

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

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

JSObject is slow: creating strings for keys and storing values by these keys after takes significant amount of time.
With this CL console methods (most of them collect top stack frame to calculate source location) are ~33% faster.
V8Debugger::captureStackTrace is ~50% faster.

BUG=v8:6189
R=yangguo@chromium.org
TBR=bmeurer@chromium.org

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

This CL cleans up a few things:
- It removes two dead declarations: WasmMemoryObject::Grow and
  wasm::GrowInstanceMemory.
- It removes the unneeded wasm::GetInstanceMemory function (use
  instance->memory_buffer() directly).
- It moves wasm::GetInstanceMemorySize to
  WasmInstanceObject::GetMemorySize.
- It moves wasm::GrowInstanceMemory to WasmInstanceObject::GrowMemory.
- It moves wasm::GrowWebAssemblyMemory to WasmMemoryObject::Grow.

R=ahaas@chromium.org
CC=gdeepti@chromium.org

Change-Id: I19781ca9784f1a8e7b60955bef82e341c4f75550
Reviewed-on: https://chromium-review.googlesource.com/463167
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44293}

This was causing GC stress failures. Garbage collections can happen during
runtime calls, such was WasmStackGuard. If the collection cleans up Wasm
objects, then they will have to modify the trap handler data structures, which
requires taking a lock. This lock can only be taken if the thread-in-wasm flag
is clear. We were getting crashes because this flag was not clear.

This change fixes the issue by making sure any runtime calls from Wasm clear the
thread-in-wasm flag and then restore it upon return. In addition, it cleans up
the code by adding a helper function that generates the code to modify the flag.

BUG= v8:6132

Change-Id: I95d43388dff60ba792c57fe13448a40a02ed4802
Reviewed-on: https://chromium-review.googlesource.com/458698
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44165}

BUG=v8:5402
R=mstarzinger@chromium.org

Change-Id: I4220cd1d7907f9c353265aeab38ee53dcf6f56b6
Reviewed-on: https://chromium-review.googlesource.com/459541Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44112}

Stack overflow checks are typically implemented as part of the TurboFan
graph of a function. This means that the stack check code is executed
after frame construction. When a frame is too big, though, there may not
be enough space on the stack anymore to throw the stack overflow
exception after frame construction. With this CL we do an additional
stack check before frame construction for functions with big frames.

As discussed offline with mstarzinger, I do this change currently only
for WebAssembly.

This CL contains only the changes for arm. I will do the other platforms
in separate CLs.

R=mstarzinger@chromium.org, v8-arm-ports@googlegroups.com

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

This CL makes the interpreter reentrant by allowing different
activations to be live at the same time. The wasm interpreter keeps a
list of activations and stores the stack height at the start of each
activation. This information is used to unwind just one activation, or
show the right portion of the interpreter stack for each interpreter
entry frame.
The WasmDebugInfo object stores a mapping from frame pointer (of the
interpreter entry) to the activation id in order to identify the
activation based on the physical interpreter entry frame.

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

Change-Id: Ibbf93f077f907213173a92e0a2f7f3556515e8eb
Reviewed-on: https://chromium-review.googlesource.com/453958
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43976}

This CL adds general lazy compilation support to WebAssembly, according
to the design described in the design doc (see referenced bug).

It's not used currently, but I tested locally that all tests succeed if
I enable it by default.

With a later CL, we will enable lazy compilation by default for
validate-asm: https://chromium-review.googlesource.com/451318

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

Change-Id: I85440382118a24fc245e78a5a90cf2b95659cd69
Reviewed-on: https://chromium-review.googlesource.com/451317
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43936}

This behaviour was missing before. If a trap is encountered in the
interpreter, we now throw the right error. With test.

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

Change-Id: I09c23d15fcde32ec586fb6d3094a5ec49155a9a2
Reviewed-on: https://chromium-review.googlesource.com/453839
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43859}

The wasm interpreter entry is only called from wasm code. Hence the
flag is cleared unconditinally before executing in the interpreter.
Note that the interpreter does not use trap handling. It can on the
other hand call to JS functions, hence the flag should not be set while
executing in the interpreter.
The flag is reset when returning from the interpreter.

This CL avoids test failures in follow-up CLs which emerged after
rebasing on the trap handler CL of eholk.

R=titzer@chromium.org, ahaas@chromium.org
CC=eholk@chromium.org
BUG=v8:5822, v8:5277

Change-Id: I8106e3a92bd9fd6159c785a718bed2d23cb3d593
Reviewed-on: https://chromium-review.googlesource.com/454676
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#43801}

This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Original-Commit-Position: refs/heads/master@{#43523}
Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43755}
Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43759}

Revert of [wasm] Initial signal handler (patchset #60 id:1170001 of https://codereview.chromium.org/2371833007/ )

Reason for revert:
ASAN breakage, such as https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/19111/steps/Check/logs/grow-memory

Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Original-Commit-Position: refs/heads/master@{#43523}
> Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43755}
> Committed: https://chromium.googlesource.com/v8/v8/+/338622d7cae787a63cece1f2e79a8b030023940b

TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

Review-Url: https://codereview.chromium.org/2371833007
Cr-Original-Commit-Position: refs/heads/master@{#43523}
Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a
Review-Url: https://codereview.chromium.org/2371833007
Cr-Commit-Position: refs/heads/master@{#43755}

Revert of [wasm] Initial signal handler (patchset #56 id:1090001 of https://codereview.chromium.org/2371833007/ )

Reason for revert:
Breaks tree, i.e. https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20ASAN/builds/18928/steps/Check/logs/grow-memory

Original issue's description:
> [wasm] Initial signal handler
>
> This is basically the minimum viable signal handler for Wasm bounds checks.
> It includes the TLS check and the fine grained instructions checks. These
> two checks provide most of the safety for the signal handler. Future CLs will
> add code range and data range checks for more robustness.
>
> The trap handling code and data structures are all in src/trap-handler, with
> the code that actually runs in the signal handler confined to
> src/trap-handler/signal-handler.cc.
>
> This changes adds a new V8 API that the embedder should call from a signal
> handler that will give V8 the chance to handle the fault first. For hosts that
> do not want to implement their own signal handler, we include the option to
> install a simple one. This simple handler is also used for the tests.
>
> When a Wasm module is instantiated, information about each function is passed
> to the trap handler, which is used to classify faults. These are removed during
> the instance finalizer.
>
> Several future enhancements are planned before turning this on by default.
> Obviously, the additional checks will be added to MaybeHandleFault. We are
> also planning to add a two-level CodeObjectData table that is grouped by
> isolates to make cleanup easier and also reduce potential for contending on
> a single data structure.
>
> BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277
>
> Review-Url: https://codereview.chromium.org/2371833007
> Cr-Commit-Position: refs/heads/master@{#43523}
> Committed: https://chromium.googlesource.com/v8/v8/+/a5af7fe9ee388a636675f4a6872b1d34fa7d1a7a

TBR=ahaas@chromium.org,bradnelson@google.com,hpayer@chromium.org,jochen@chromium.org,mark@chromium.org,mseaborn@chromium.org,titzer@chromium.org,eholk@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

This is basically the minimum viable signal handler for Wasm bounds checks.
It includes the TLS check and the fine grained instructions checks. These
two checks provide most of the safety for the signal handler. Future CLs will
add code range and data range checks for more robustness.

The trap handling code and data structures are all in src/trap-handler, with
the code that actually runs in the signal handler confined to
src/trap-handler/signal-handler.cc.

This changes adds a new V8 API that the embedder should call from a signal
handler that will give V8 the chance to handle the fault first. For hosts that
do not want to implement their own signal handler, we include the option to
install a simple one. This simple handler is also used for the tests.

When a Wasm module is instantiated, information about each function is passed
to the trap handler, which is used to classify faults. These are removed during
the instance finalizer.

Several future enhancements are planned before turning this on by default.
Obviously, the additional checks will be added to MaybeHandleFault. We are
also planning to add a two-level CodeObjectData table that is grouped by
isolates to make cleanup easier and also reduce potential for contending on
a single data structure.

BUG= https://bugs.chromium.org/p/v8/issues/detail?id=5277

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

The only remaining allowed occurence of a context is in WASM_TO_JS
code, which is regenerated for each instance.
This CL removes all the rest, to avoid subtle bugs where we might
forget to patch it. By renaming the BuildCallToRuntime method, we make
sure that noone accidentially calls the version which embeds a context.
For consistency, I even remove it from the WasmRunInterpreter stub,
which is never reused for new instantiations.

R=titzer@chromium.org

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

With this CL the out-of-line code of TrapIf will call a builtin instead
of doing a direct runtime call, which is cheaper. In the best case, the
out-of-line code now consists of a single call instruction. The builtin
will load the trapID and then call the runtime to throw a trap.

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

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

Instead of placing a runtime call to StackGuard in the compiled wasm
code, we just call the builtin, which is cheaper. By passing Smi::kZero
as context, we save even more code space and avoid embedding the
context in the code.
The WasmStackGuard builtin then calls the new WasmStackGuard runtime
function, which gets the context from the instance attached to the
calling wasm code, and then does the usual StackGuard logic.

For the unity benchmark in asm-wasm mode, generated code size reduces
from 63.0 to 61.6 MB (-2.1%).

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

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

This is the first step to reduce the size of the out-of-line code of
TrapIf. Instead of passing the context to the runtime call as a
parameter, we pass Smi::kZero to the runtime call and then get the
actual context from the WasmFrame on the stack.

BUG=v8:5908
R=titzer@chromium.org, clemensh@chromium.org

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

and add an inspector test for it. Also test that a breakpoint can be
set on each reported position, and that it is also hit during
execution.
This CL also fixes two little things which were uncovered by the new
test.

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

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

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}

Also, add a runtime function to call the interpreter, passing a
stack-allocated buffer holding the arguments.
The WASM_INTERPRETER_ENTRY stub allocates the stack slot for the
arguments, fills it, and calls to the wasm interpreter.
It's abi is compatible with WASM functions, such that we can just
replace a call to a WASM_FUNCTION with a call to
WASM_INTERPRETER_ENTRY.
See tracking bug to get the overall picture.

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

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

Plus another minor refactoring.

R=titzer@chromium.org

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

Some instructions in WebAssembly trap for some inputs, which means that the
execution is terminated and (at least at the moment) a JavaScript exception is
thrown. Examples for traps are out-of-bounds memory accesses, or integer
divisions by zero.

Without the TrapIf and TrapUnless operators trap check in WebAssembly introduces 5
TurboFan nodes (branch, if_true, if_false, trap-reason constant, trap-position
constant), in addition to the trap condition itself. Additionally, each
WebAssembly function has four TurboFan nodes (merge, effect_phi, 2 phis) whose
number of inputs is linear to the number of trap checks in the function.
Especially for functions with high numbers of trap checks we observe a
significant slowdown in compilation time, down to 0.22 MiB/s in the sqlite
benchmark instead of the average of 3 MiB/s in other benchmarks. By introducing
a TrapIf common operator only a single node is necessary per trap check, in
addition to the trap condition. Also the nodes which are shared between trap
checks (merge, effect_phi, 2 phis) would disappear. First measurements suggest a
speedup of 30-50% on average.

This CL only implements TrapIf and TrapUnless on x64. The implementation is also
hidden behind the --wasm-trap-if flag.

Please take a special look at how the source position is transfered from the
instruction selector to the code generator, and at the context that is used for
the runtime call.

R=titzer@chromium.org

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

I removed {IsWasmInstance} because it is not used anywhere, and I moved
ThrowWasmError to runtime-wasm.cc

R=titzer@chromium.org

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

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Original-Commit-Position: refs/heads/master@{#41198}
Cr-Commit-Position: refs/heads/master@{#41234}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #13 id:240001 of https://codereview.chromium.org/2471883003/ )

Reason for revert:
Test crashes after an unrelated revert: https://chromegw.corp.google.com/i/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7189

Reverting because of recommendation from WASM team.

Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
>  - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
>  - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
>  - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
>  - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
>  R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Committed: https://crrev.com/3c98e339599b068f1ed630afb7601ff942424d31
> Cr-Original-Commit-Position: refs/heads/master@{#41121}
> Cr-Commit-Position: refs/heads/master@{#41198}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@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/2529573002
Cr-Commit-Position: refs/heads/master@{#41208}

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
Review-Url: https://codereview.chromium.org/2471883003
Cr-Original-Commit-Position: refs/heads/master@{#41121}
Cr-Commit-Position: refs/heads/master@{#41198}

Revert of [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects. (patchset #10 id:180001 of https://codereview.chromium.org/2471883003/ )

Reason for revert:
Breaks gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20gc%20stress/builds/7114

Original issue's description:
> [wasm] WebAssembly.Memory object can be referenced by multiple Instance objects.
>
> Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
>  - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
>  - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
>  - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
>  - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.
>
>  R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org
>
> Committed: https://crrev.com/30ef8e33f3a199a27ca8512bcee314c9522d03f6
> Cr-Commit-Position: refs/heads/master@{#41121}

TBR=bradnelson@chromium.org,mtrofin@chromium.org,titzer@chromium.org,gdeepti@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/2512323004
Cr-Commit-Position: refs/heads/master@{#41122}

Add support for WebAssembly.Memory objects to be simultaneously referenced by multiple Instance objects. GrowingMemory should maintain a consistent view of memory across instances.
 - Store a link to instances that share WebAssembly.Memory in the WasmMemoryObject, updated on instantiate.
 - Implement WasmInstanceWrapper as a wrapper around the instance object to keep track of previous/next instances, instance object is stored as a WeakCell that can be garbage collected.
 - MemoryInstanceFinalizer maintains a valid list of instances when an instance is garbage collected.
 - Refactor GrowInstanceMemory to GrowMemoryBuffer that allocates a new buffer, and UncheckedUpdateInstanceMemory that updates memory references for an instance.

 R=titzer@chromium.org, mtrofin@chromium.org, bradnelson@chromium.org

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

R=clemensh@chromium.org,mtrofin@chromium.org
BUG=

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

The implementation of MemorySize with RelocatableInt32Constants is
problematic if MemorySize is placed close to a GrowMemory instruction in
the code. The use of a runtime function guarantees that the order in
which MemorySize and GrowMemory is executed is correct.

R=titzer@chromium.org
BUG=chromium:651961
TEST=mjsunit/regress/wasm/regression-651961

Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
Review-Url: https://codereview.chromium.org/2386183004
Cr-Original-Commit-Position: refs/heads/master@{#39972}
Cr-Commit-Position: refs/heads/master@{#39980}

Revert of [wasm] Call a runtime function for a MemorySize instruction. (patchset #2 id:20001 of https://codereview.chromium.org/2386183004/ )

Reason for revert:
Patch problem

Original issue's description:
> [wasm] Call a runtime function for a MemorySize instruction.
>
> The implementation of MemorySize with RelocatableInt32Constants is
> problematic if MemorySize is placed close to a GrowMemory instruction in
> the code. The use of a runtime function guarantees that the order in
> which MemorySize and GrowMemory is executed is correct.
>
> R=titzer@chromium.org
> BUG=chromium:651961
> TEST=mjsunit/regress/wasm/regression-651961
>
> Committed: https://crrev.com/2c12a9a42d454a36fcd2931fa458d72832eeb689
> Cr-Commit-Position: refs/heads/master@{#39972}

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

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