It appears in the cctest context, both the old STUB, and the current
WASM_FUNCTION "just work"; however, in the upcoming off-the-gc wasm
world, we codegen call sites differently on x64 - far calls for
js-to-wasm (this case), and near calls otherwise.
Bug:
Change-Id: Iebf8acf164f07742fc367b7bbf266913dbc60c46
Reviewed-on: https://chromium-review.googlesource.com/735131
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48889}
Ensure that effect outputs from nodes are used if they have
an effect output. This helps us avoid an easy-to-make error
where we fail to update the effect chain with the result of
effectful operations.
Bug: v8:6929
Change-Id: I585dc627b3c330006ec04717ff9b2f5060dbad6a
Reviewed-on: https://chromium-review.googlesource.com/718107
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48861}
There are wasm operations which operate on floats or double, but they
need to preserve the exact bit pattern. Thus they cannot be stored and
passed as float or double, since that might flip the signaling NaN bit.
This CL extends WasmValue to store floats and doubles as bit pattern,
and adds accessors to extract them as Float32 or Float64.
The interpreter is changed to execute certain operations (i32.abs,
i32.neg, i64.abs, i64.neg, f32.reinterpret/i32, f64.reinterpret/i64) on
boxed floats.
R=titzer@chromium.org
Bug: v8:6954
Change-Id: I0251d1a67b6caf593194d4eb292a325cdd3f20cf
Reviewed-on: https://chromium-review.googlesource.com/730716
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48819}
This is a reland of 6f93d59d92.
One more test had to be disabled (tracked by bug 6954), and
two machops tests needed to be changed to use boxed floats
and doubles.
Original change's description:
> [test] Add nan bit patterns to uint{32,64}_vector
>
> If you just cast those patterns to float or double and pass them
> around, the quiet/signaling NaN bit might change. We had several bugs
> around this, so add these patterns to the general input vectors.
>
> This uncovers a bug in the wasm interpreter, which will be fixed in a
> separate CL.
>
> R=ahaas@chromium.org
>
> Bug: v8:6947, v8:6954
> Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
> Reviewed-on: https://chromium-review.googlesource.com/725345
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48731}
Bug: v8:6947, v8:6954
Change-Id: I9a38b5d9324131c3950c537910371a73c93d2c13
Reviewed-on: https://chromium-review.googlesource.com/728439
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48780}
This reverts commit 6f93d59d92.
Reason for revert: Breaks full-debug build:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20full%20debug/builds/2239
Original change's description:
> [test] Add nan bit patterns to uint{32,64}_vector
>
> If you just cast those patterns to float or double and pass them
> around, the quiet/signaling NaN bit might change. We had several bugs
> around this, so add these patterns to the general input vectors.
>
> This oncovers a bug in the wasm interpreter, which will be fixed in a
> separate CL.
>
> R=ahaas@chromium.org
>
> Bug: v8:6947, v8:6954
> Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
> Reviewed-on: https://chromium-review.googlesource.com/725345
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48731}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: I4ceb82eab5d4cbf1f335bf6f358178a17a2fd0ba
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6947, v8:6954
Reviewed-on: https://chromium-review.googlesource.com/728101
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48745}
If you just cast those patterns to float or double and pass them
around, the quiet/signaling NaN bit might change. We had several bugs
around this, so add these patterns to the general input vectors.
This oncovers a bug in the wasm interpreter, which will be fixed in a
separate CL.
R=ahaas@chromium.org
Bug: v8:6947, v8:6954
Change-Id: I205b8ab784b087b1e4988190fa725df0b90e7ee0
Reviewed-on: https://chromium-review.googlesource.com/725345
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48731}
This is a reland of e737b4ce0d.
The issue on windows bots was fixed in https://crrev.com/c/725733.
Original change's description:
> [test] Avoid unnecessary std::vector allocations
>
> Instead of copying an array of fixed values into an std::vector for
> each usage of the FOR_INPUTS macro, just iterate the constant data
> directly.
> This also makes the <type>_vector() functions return {constexpr Vector}
> instead of {std::vector}.
>
> R=tebbi@chromium.org
>
> Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
> Reviewed-on: https://chromium-review.googlesource.com/725427
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48688}
Change-Id: I9ad5d22803bbbf35c458965497acc603cfa01b20
Reviewed-on: https://chromium-review.googlesource.com/725979
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48726}
This reverts commit e737b4ce0d.
Reason for revert: On windows, V8_INFINITY is not constexpr
Original change's description:
> [test] Avoid unnecessary std::vector allocations
>
> Instead of copying an array of fixed values into an std::vector for
> each usage of the FOR_INPUTS macro, just iterate the constant data
> directly.
> This also makes the <type>_vector() functions return {constexpr Vector}
> instead of {std::vector}.
>
> R=tebbi@chromium.org
>
> Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
> Reviewed-on: https://chromium-review.googlesource.com/725427
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48688}
TBR=clemensh@chromium.org,tebbi@chromium.org
Change-Id: Iccb52941d4efe71b49b41572c3d922a5d78bdfd2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/725899
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48691}
Instead of copying an array of fixed values into an std::vector for
each usage of the FOR_INPUTS macro, just iterate the constant data
directly.
This also makes the <type>_vector() functions return {constexpr Vector}
instead of {std::vector}.
R=tebbi@chromium.org
Change-Id: Ifc3e5509b2fbf5e383c967c2f46acf2b07f7b5b4
Reviewed-on: https://chromium-review.googlesource.com/725427
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48688}
This is needed for proper deserialization of code and has the nice
side effect of fixing the nasty race condition that led us to
introducing a lock on the signature map.
R=mtrofin@chromium.orgCC=clemensh@chromium.org
Bug:
Change-Id: I6a018344ad8b58b088b20756d3b00ae08232bbb9
Reviewed-on: https://chromium-review.googlesource.com/718937
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48589}
With the introduction of the WasmContext, compiled code is no longer
specialized to the memory start and size (or recently, globals_start).
This CL uses the same WasmContext between the interpreter and compiled
code, removing the need for UpdateMemory() and cached instance info.
R=clemensh@chromium.org
Bug:
Change-Id: I0bd52352c9b6f3029246e94e239dc29f635e7920
Reviewed-on: https://chromium-review.googlesource.com/712734
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48584}
This CL removes the code specialization for WASM functions that access
globals. Previously, we were embedding the start address of the globals
memory (globals_start) as a constant in the code, which required
patching for every instance. We now put this base in to the WasmContext,
which is available as a parameter to every WasmFunction.
R=ahaas@chromium.org,
CC=mtrofin@chromium.org
Bug:
Change-Id: I04bb739e898cc5a3b7dd081cc166483022d113fd
Reviewed-on: https://chromium-review.googlesource.com/712595
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48581}
This flag describes that the memory defined in a wasm module has a
maximum size. Therefore I think kHasMaximumFlag is more appropriate.
R=titzer@chromium.org
Bug: v8:6921
Change-Id: Ie794d670f74e7f1f9a42822e2f774da85aaaaa4b
Reviewed-on: https://chromium-review.googlesource.com/718198
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48517}
Only change over original: Init sig_index to 0 at
function-body-decoder-impl.h:168, to make MSAN happy on error path.
R=titzer@chromium.org
Change-Id: I9ac17215360523b656b10d2466201001b65992c0
Reviewed-on: https://chromium-review.googlesource.com/712655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Rossberg <rossberg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48463}
This flag was originally added as a staging mechanism to let us land and test
guard regions without the full trap handler feature landing. Additionally, we
thought we might enable guard regions without trap handlers on some systems.
Trap handlers are now supported, and there's not a real compelling reason for
why we need guard regions without trap handlers. Keeping the separate flag leads
to confusion, since some code treats guard regions and trap handlers the same,
while other code treats them as independent.
Removing this flag and its associated special cases makes everything more
uniform and predictable.
R=gdeepti@chromium.org
Change-Id: Icebab91d1f1e0c55e7a35c75b880085d37fa14ae
Reviewed-on: https://chromium-review.googlesource.com/706570
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48411}
This ensures that platform is initialized before the isolate and
properly restores the previous platform at the end of the test.
Bug:
Change-Id: I2771b7538362c400c5ff61411222beb7d7e62b02
Reviewed-on: https://chromium-review.googlesource.com/707111
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48405}
Fix disassembly of atomic operations for the inspector.
BUG=v8:6842,v8:6532
Change-Id: I3701b55c28b10561d1726e2c0b9fe2e1b2c76b8e
Reviewed-on: https://chromium-review.googlesource.com/703468
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48324}
This adds a new simd lowering execution mode for
simd and re-enables the lowering tests
R=titzer@chromium.org,gdeepti@chromium.org,bbudge@chromium.org,mtrofin@chromium.org
BUG=v8:6020
Change-Id: Ice6b7ff2f5973804d379c88241d49b811429a965
Reviewed-on: https://chromium-review.googlesource.com/698928
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48322}
CCalls have significantly less overhead than runtime calls which will improve
runtime performance on programs that make lots of transitions between JS and
Wasm.
Bug: v8:5277
Change-Id: If09dea97f24eb43753847e2b894ebc1ba5168c23
Reviewed-on: https://chromium-review.googlesource.com/688481
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48297}
We had dangling pointers by storing a raw pointer and then discarding
the unique_ptr holding it alive, and we had lots of redundant
information there.
This CL refactors the interface to take a format string and a variable
number of argument.
R=titzer@chromium.org
Change-Id: I8eb6ccd19d307e2477c97a3e5e7f537b5671a891
Reviewed-on: https://chromium-review.googlesource.com/690196
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48223}
The WasmContext struct introduced in this CL is used to store the
mem_size and mem_start address of the wasm memory. These variables can
be accessed at C++ level at graph build time (e.g., initialized during
instance building). When the GrowMemory runtime is invoked, the context
variables can be changed in the WasmContext at C++ level so that the
generated code will load the correct values.
This requires to insert a relocatable pointer only in the
JSToWasmWrapper (and in the other wasm entry points), the value is then
passed from function to function as an automatically added additional
parameter. The WasmContext is then dropped when creating an Interpreter
Entry or when invoking a JavaScript function. This removes the need of
patching the generated code at runtime (i.e., when the memory grows)
with respect to WASM_MEMORY_REFERENCE and WASM_MEMORY_SIZE_REFERENCE.
However, we still need to patch the code at instance build time to patch
the JSToWasmWrappers; in fact the address of the WasmContext is not
known during compilation, but only when the instance is built.
The WasmContext address is passed as the first parameter. This has the
advantage of not having to move the WasmContext around if the function
does not use many registers. This CL also changes the wasm calling
convention so that the first parameter register is different from the
return value register. The WasmContext is attached to every
WasmMemoryObject, to share the same context with multiple instances
sharing the same memory. Moreover, the nodes representing the
WasmContext variables are cached in the SSA environment, similarly to
other local variables that might change during execution. The nodes are
created when initializing the SSA environment and refreshed every time a
grow_memory or a function call happens, so that we are sure that they
always represent the correct mem_size and mem_start variables.
This CL also removes the WasmMemorySize runtime (since it's now possible
to directly retrieve mem_size from the context) and simplifies the
GrowMemory runtime (since every instance now has a memory_object).
R=ahaas@chromium.org,clemensh@chromium.org
CC=gdeepti@chromium.org
Change-Id: I3f058e641284f5a1bbbfc35a64c88da6ff08e240
Reviewed-on: https://chromium-review.googlesource.com/671008
Commit-Queue: Enrico Bacis <enricobacis@google.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48209}
Note that this also makes it possible to move several classes
into the module-compiler.cc file and inline their implementations.
This also allows removing several uses of wasm-module.h from
other places in V8 that include wasm-objects.h.
R=yangguo@chromium.org,clemensh@chromium.org,ahaas@chromium.org
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I303ee2bb49dc53c951d377a1b65699c1e0e91da7
Reviewed-on: https://chromium-review.googlesource.com/687494
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48204}
In the test-run-wasm and test-run-wasm-64 cctests it is not possible to
call runtime functions. To test traps in these cctests we therefore
replace the runtime call with a call to a c-callback, followed by a
return. This CL fixes the problem that the return did not clean up stack
parameters.
This CL unblocks
https://chromium-review.googlesource.com/c/v8/v8/+/671008. Originally I
wanted to mitigate the problem in that CL by defining an additional
parameter register for arm. However, adding additional parameter
registers lets other tests fail.
R=titzer@chromium.org, rodolph.perfetta@arm.comCC=enricobacis@google.com
Bug: v8:6858
Change-Id: Ia8de73b70a0677ca4d379ed5b16272faee92a78d
Reviewed-on: https://chromium-review.googlesource.com/684017
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48158}
Previously, we would blindly register new handler data, leading to us leaking
the old handler data. This meant we could then end up with overlapping handler
data where the instruction offset and landing pads didn't line up right.
Bug: v8:6841
Change-Id: Iedcd75925b8d9d59c8f9accf288cae954fdc568f
Reviewed-on: https://chromium-review.googlesource.com/677632
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48144}
This change enables moving the WasmToJSWrapper off the GCed heap
R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Bug:
Change-Id: I1ea8810fa7b71bcb2a80a1390742db64872c5bb1
Reviewed-on: https://chromium-review.googlesource.com/665977
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48118}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
This fixes a few leftovers where we use WASM_EXEC_TEST, but then
unconditionally execute the compiled code, and also changes more tests
to use WASM_EXEC_TEST, hence run in both the interpreter and compiled
code.
Once we have land the baseline compiler, those tests will also execute
in baseline compilation mode.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I79598df21a7538934306e01ca6593f05afe19ed3
Reviewed-on: https://chromium-review.googlesource.com/672528
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48091}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=ahaas@chromium.org
Bug: v8:6837
Change-Id: Ic8966dfeacf02b2684eeef23fde99ec2be4ed81e
Reviewed-on: https://chromium-review.googlesource.com/671364
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48080}
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.
In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.
Bug:v8:6785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
- Validate that atomic ops can only be called when shared memory is declared
- Throw Compile/Link erros on mismatch between declared, imported memory
- Test harness helpers for setting shared memory, tests
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I43fe3d04bb7e3e0a2cecca0528578f98844d2608
Reviewed-on: https://chromium-review.googlesource.com/665379
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48019}
This further reduces the amount of test-specific code. It will also
help testing the wasm baseline compiler, since it is also being called
from the {WasmCompilationUnit}.
Also, move the {RuntimeExceptionSupport} flag from the
{WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need
to store this per function builder. The {TestingModuleBuilder} then
passes it on to the {WasmCompilationUnit}, which finally sets it on the
{WasmGraphBuilder}.
R=mtrofin@chromium.org
Bug: v8:6600
Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee
Reviewed-on: https://chromium-review.googlesource.com/660239
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47970}
We were using a boolean before, which makes the meaning non-obvious
when passed as a parameter. With the enum, you actually have to use
{kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}.
R=mtrofin@chromium.org
Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49
Reviewed-on: https://chromium-review.googlesource.com/660738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47969}
- Memory.Grow with guard pages enabled should adjust amount of allocated
memory, and not allocate a new buffer. This was disabled because previously
the backing store was freed in the MemoryFinalizer, and we needed to be sure
that the backing store is not released till the last buffer using it is
released. This is now safe as we no longer use the MemoryFinalizer
- SetProtection should use Guard/Unprotect that use mprotect underneath,
instead of CommitRegion/UncommitRegion that use mmap
- Move buffer allocation to the end to avoid inconsistent memory due to GC
BUG=v8:5886
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0d7edb884bd1e3167eb5fbced6953c6401688d40
Reviewed-on: https://chromium-review.googlesource.com/629517
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47960}
