|is_posix| will be switched to false for Fuchsia, this is a preliminary change.
Bug: chromium:812974
Change-Id: I2ae8e5ef4270cd0acbc7c69bb46d1be9ed4a5c5e
Reviewed-on: https://chromium-review.googlesource.com/988253
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Fabrice de Gans-Riberi <fdegans@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52407}
The AssembleMove and AssembleSwap tests would only perform moves on stack
parameters. This limits us to testing with slots that are likely to be in range
of loads and stores. As well as only testing memory accesses with positive
offsets relative to the frame pointer.
This patch addresses these limitations by moving half of the stack parameters
into spill slots, to then perform moves on them. Additionally, to increase
ranges, we create articial space between each spilled slot.
As a drive-by, allow giving custom names to code objects created with the
CodeAssemblerTester. It helps a lot inspecting disassembly.
And finally, this CL uncovered a bug where I had forgotten to initialize
FixedArrays, which would make the incremental marker crash.
Bug: v8:6848
Change-Id: Ic1954c1896130f6c55e09a3068bf341cc4c68670
Reviewed-on: https://chromium-review.googlesource.com/980613
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52406}
This CL further lowers the kMaxEmptyFactor constant to more aggressively shrink
the StringTable when it's empty.
Bug: v8:5443, chromium:818642
Change-Id: I1c263a0afd7e6bed8a8bb857db032bf126c3ef4b
Reviewed-on: https://chromium-review.googlesource.com/995473
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52401}
This is a small step towards making node build on Windows.
Bug: v8:6105
R=machenbach@chromium.org
Change-Id: I8d3a9b1830bb012d846a791fddc8d1d8d830515e
Reviewed-on: https://chromium-review.googlesource.com/980950
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52400}
This adds support for i64.and, i64.or and i64.xor.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ie64e1874f87cd250f3e0641e021f584ecd0aaff9
Reviewed-on: https://chromium-review.googlesource.com/995444
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52396}
The amortized cost of a single invocation is actually O(1), not O(n).
But this whole comment is needless anyway, so just remove it.
R=ahaas@chromium.org
NOTRY=true
Change-Id: Icffaedcd784584b1676cd7ed323555177a62d63e
Reviewed-on: https://chromium-review.googlesource.com/997812
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52395}
It looks like the normal ways of creating lookup iterators work better.
Bug: v8:5988, chromium:828282
Change-Id: Ifd623b2e93708ff8684d056d9292b7779f611a3c
Reviewed-on: https://chromium-review.googlesource.com/997474
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52392}
Add support for decoding anyref globals, and some drive-by cleanups.
R=titzer@chromium.org
Bug: v8:7581
Change-Id: I3527f996a3fa1a890918a5924e951fbafa394cf2
Reviewed-on: https://chromium-review.googlesource.com/997655
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52391}
This is a reland of 63ecddc814
Original change's description:
> [runtime] Remove the construct_stub field of the SFI
>
> Don't dispatch based on the construct_stub field anymore. Rather than
> read it out and jump to the construct stub, we can switch on the
> builtin_id.
>
> Builtins will always have builtin_id as a Smi, so this signals we need
> to jump to JSBuiltinsConstructStub. The only exception is for uncompiled
> functions, which will have kCompileLazy as the builtin_id, but need to
> jump to the generic stub instead.
>
> API function calls will have a FunctionTemplateInfo in the SFI
> function_data field, and need to go to the builtins stub as well.
>
> The final case is everything else, which should go to the generic stub.
>
> Bug: v8:7503
> Change-Id: I14790a5f9784dc0d940bf10a05f5310026e1d482
> Reviewed-on: https://chromium-review.googlesource.com/980941
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52345}
TBR=bmeurer@chromium.org
Bug: v8:7503
Change-Id: Ie46bfb0af173ad7ac8cbdfeed1865e60f3f413f7
Reviewed-on: https://chromium-review.googlesource.com/997712
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52389}
Fixes a crash that happens when calling postMessage on an empty typed
array.
GetBuffer should only call MaterializeArrayBuffer for on-heap buffers,
but the on-heap check is slightly wrong. This CL moves the on-heap check
logic to the JSTypedArray class so that other parts of the codebase
don't need to worry about how that is determined.
Also add some dchecks to materialize itself. It should only receive
on-heap buffers and should always transform them to off-heap buffers.
There is also no reason for it to be static, so change that here too.
Bug: chromium:797588
Change-Id: Icd88a5b68e424d82c9f1f7889ca42a40a72a1bdc
Reviewed-on: https://chromium-review.googlesource.com/995898
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52388}
In order to clarify the difference between, e.g., InstructionStart and
instruction_start, rename as follows:
Code::instruction_start -> raw_instruction_start
Code::instruction_end -> raw_instruction_end
Code::instruction_size -> raw_instruction_size
The difference between the camel-case and raw_* function families is
in how they handle off-heap-trampoline Code objects. For example, when
called on an off-heap-trampoline: raw_instruction_start returns the
trampoline's entry point, while InstructionStart returns the off-heap
code's entry point (located in the .text section of the binary).
Some callsites were updated to call the camel-case function family as
appropriate.
Bug: v8:6666
Change-Id: I4a572f47c2d161a853599d7c17879e263b0d1a87
Reviewed-on: https://chromium-review.googlesource.com/997532
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52387}
This pattern seems to reoccur in the code:
Handle<TransitionArray> array = TransitionArray::Allocate(...);
<something that causes allocation>
// Fill up the array
array->set(...);
If the allocation causes GC, we try to iterate the TransitionArrray
in MarkCompactCollector::ClearFullMapTransitions, and that crashes because it
expects the TransitionArray to contain handlers (not undefined).
This bug is present e.g., in TransitionAccessor::EnsureHasFullTransition.
BUG=v8:7308
Change-Id: I306204fc27d62041801427c466c82d1d9df1bf0c
Reviewed-on: https://chromium-review.googlesource.com/997493
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52386}
In addition, remove the default branch from the swtich in HeapObjectPrint, so
that it's no longer possible to leave out printing functionality by accident.
BUG=v8:7308
Change-Id: I2db67549e328aea6228d3a370f9ebb7494ab3730
Reviewed-on: https://chromium-review.googlesource.com/997492
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52384}
Removing these tests from skip list because corresponding wasm simd
opcodes lowering has been implemented.
Change-Id: I77bbbee573ba65cf27dc9ee39f4d352bafb5849f
Reviewed-on: https://chromium-review.googlesource.com/988032
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#52383}
This is a reland of 5ae8420c28
Original change's description:
> [Liftoff] Implement float rounding
>
> This adds support for the four rounding operations on f32 and f64:
> f32.ceil, f32.floor, f32.trunc, f32.nearest_int, f64.ceil, f64.floor,
> f64.trunc, and f64.nearest_int.
>
> R=titzer@chromium.org
>
> Bug: v8:6600
> Change-Id: I16ea91e26c3233af7a33bbb794cd4182f9d7cdb0
> Reviewed-on: https://chromium-review.googlesource.com/995894
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52377}
Bug: v8:6600
Change-Id: I9e69309b71041e411bda9ce1375d2451197a111b
Reviewed-on: https://chromium-review.googlesource.com/997393
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52382}
mjsunit/harmony/bigint/typedarray test failure on mips32 big endian
pointed there was a problem.
Change-Id: I016a31d7758e7bd4019210e23c147dc0f8ea893f
Reviewed-on: https://chromium-review.googlesource.com/995455
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52380}
This adds support for the four rounding operations on f32 and f64:
f32.ceil, f32.floor, f32.trunc, f32.nearest_int, f64.ceil, f64.floor,
f64.trunc, and f64.nearest_int.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I16ea91e26c3233af7a33bbb794cd4182f9d7cdb0
Reviewed-on: https://chromium-review.googlesource.com/995894
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52377}
test-heap/TransitionsArraySimpleToFull was relying on an allocation
happening (and GC being triggered) right at the start of
TransitionsAccessor::Insert. That allocation would put the TransitionsAccessor
back to the kUninitialized state. If there's no allocation at that point of the
program logic, the test will fail, since the TransitionsAccessor will be go to
the kFullTransitionArray state.
(Needed for the in-place weak ref work, which will remove the allocation at that point.)
BUG=v8:7308
Change-Id: Id3985e107d86440fe05daf5f3f29c84d028df929
Reviewed-on: https://chromium-review.googlesource.com/995476
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52374}
This is a reland of 7a2c371383
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
Bug: v8:7588
Change-Id: Ibc92bf19155f2ddaedae39b0c576b994e84afcf8
Reviewed-on: https://chromium-review.googlesource.com/996760
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52373}
This is a reland of dbdede0101
after a webkit layout test (geolocation-api/timestamp.html) was
fixed by
https://chromium-review.googlesource.com/c/chromium/src/+/994343 .
Original change's description:
> Implement a new spec for timezone offset calculation
>
> https://github.com/tc39/ecma262/pull/778 was recently merged
> to Ecma 262.
>
> It changes the way to convert between "local time" and UTC in such
> a way that it'd work for all timezones whether or not there has
> been any change in the timezone offset of the standard time. For
> instance, Europe/Moscow and some parts of US state of Indiana have
> changed the standard (non-DST) timezone offset a few times. The
> previous spec assumes that the the standard timezone offset is
> constant, but the new spec take into account the offset change
> history.
>
> In addition, it specifies a new way to calculate the timezone
> offset during a timezone transition (either in and
> out of DST or timezone offset shift).
>
> During a negative transition (e.g. fall backward / getting
> out of DST), repeated times are to be interpreted as if the
> offset before the transition is in effect.
>
> During a positive transition (e.g. spring forward / getting
> into DST), skipped times are to be treated similarly. That
> is, they are to be interpreted as if the offset before the
> transition is in effect.
>
> With icu-timezone-data, v8 is compliant to the new spec for the
> past and the future as well as now whether or not the standard
> timezone offset of a given timezone has changed over time
> (e.g. Europe/Moscow, Pacific/Apia). With icu-timezone-data,
> Australia/Lord_Howe (30 minute DST change) also works per spec.
>
> Without icu-timezone-data, it works only for timezones of which
> the standard timezone offset is the same as the current offset
> (e.g. most North American timezones other than parts of Indiana)
> and of which the DST shift is an hour. For instance, it doesn't work
> for Europe/Moscow in 2010 when the standard timezone offset was
> +4h because the current (2018) standard timezone offset is +3h. Neither
> does it for Lord Howe in Australia with the DST shift of 0.5 hr.
>
> This CL used to require one of the two ICU CLs below, but not
> any more.
>
> https://chromium-review.googlesource.com/c/chromium/deps/icu/+/572652
> https://chromium-review.googlesource.com/851265 (a proposed CL to the
> upstream ICU).
>
> Bug: v8:3547,chromium:417640,v8:5714
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Ib162295da5bee31b2390bd0918157014aebd3e33
> Reviewed-on: https://chromium-review.googlesource.com/572148
> Commit-Queue: Jungshik Shin <jshin@chromium.org>
> Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52332}
Bug: v8:3547, chromium:417640, v8:5714
Change-Id: I47536c111143f75e3cfeecf5d9761c43a98a10f5
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/995971
Commit-Queue: Jungshik Shin <jshin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52372}
This reverts commit 7a2c371383.
Reason for revert: msan is broken
Original change's description:
> [debug] introduced runtime side effect check
>
> This CL demonstrates minimum valuable addition to existing debug evaluate
> without side effects mechanism.
> With this CL user can evaluate expressions like:
> [a,b] // create any kind of temporary array literals
> [a,b].reduce((x,y) => x + y, 0); // use reduce method
> [1,2,3].fill(2); // change temporary arrays
>
> The core idea: any change of the object created during evaluation without
> side effects is side effect free. As soon as we try to store this temporary
> object to object existed before evaluation we will terminate execution.
>
> Implementation:
> - track all objects allocated during evaluation and mark them as temporary,
> - patch all bytecodes which change objects.
>
> A little more details (including performance analysis): [1].
>
> [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
>
> Bug: v8:7588
> Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
> Reviewed-on: https://chromium-review.googlesource.com/972615
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52370}
TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7588
Reviewed-on: https://chromium-review.googlesource.com/996135
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52371}
This CL demonstrates minimum valuable addition to existing debug evaluate
without side effects mechanism.
With this CL user can evaluate expressions like:
[a,b] // create any kind of temporary array literals
[a,b].reduce((x,y) => x + y, 0); // use reduce method
[1,2,3].fill(2); // change temporary arrays
The core idea: any change of the object created during evaluation without
side effects is side effect free. As soon as we try to store this temporary
object to object existed before evaluation we will terminate execution.
Implementation:
- track all objects allocated during evaluation and mark them as temporary,
- patch all bytecodes which change objects.
A little more details (including performance analysis): [1].
[1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
Bug: v8:7588
Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
Reviewed-on: https://chromium-review.googlesource.com/972615
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52370}
With the Ignition + Turbofan pipeline there is very little overlap between the data
needed for unoptimized compilation and optimized compilation. As a result, it is
cleaner to split up the CompilationInfo into UnoptimizedCompilationInfo and
OptimizedCompilationInfo.
Doing so also necessitate splitting up CompilationJob into UnoptimizedCompilationJob
and OptimizedCompilationJob - again there is not much overlap so this seems cleaner.
Change-Id: I1056ad520937b7f8582e4fc3ca8f4910742de30a
Reviewed-on: https://chromium-review.googlesource.com/995895
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52369}
The first part of this change updates StoreMem_offset_oob_i64 to use one page of
Wasm memory, rather than just a few bytes. Using less than a page was out of
spec for Wasm anyway, so this is better.
This required a small change in the test runner to set and clear the
thread_in_wasm flag around Wasm calls. This was accomplished by a
ThreadInWasmScope convenience class.
The majority of the changes are because the cctest environment does not support
runtime exceptions. In the code generator, where we used to throw a
WasmMemOutOfBounds exception, we now need to call out to the test hook instead
if runtime exceptions are not supported. This involved plumbing the
runtime_exception_support flag down to the code generator. Rather than adding
and shuffling around extra parameters everywhere, this CL packages the previous
protected instruction list in a new WasmCompilationData object that now includes
the runtime_exception_support flag as well.
Bug: v8:5277
Change-Id: Ic9c9e5a53a07a7773b58c0aee7c26bbd2ddf82f3
Reviewed-on: https://chromium-review.googlesource.com/989017
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52368}
This exposes new flags to allow embedders to whitelist callbacks as
side-effect-free during evaluation with throwOnSideEffect.
Accessors and Functions/FunctionTemplates can take a new param on:
- v8::Object::SetNativeDataProperty
- v8::Object::SetLazyDataProperty
- v8::Object::SetAccessor
- v8::FunctionTemplate::New
- v8::FunctionTemplate::NewWithCache
- v8::Function::New
While Interceptors can be created with an additional flag:
PropertyHandlerFlag::kHasNoSideEffect
Bug: v8:7515
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I14823316bdd6de6d362a1104b65f13504d0db056
Reviewed-on: https://chromium-review.googlesource.com/994550
Commit-Queue: Erik Luo <luoe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52367}
The phantom handle API requires that the first pass callback does not
invoke any V8 API. The current code breaks this requirement by invoking
AdjustAmountOfExternalAllocatedMemory, which can cause GC.
This patch splits the existing callback into two parts. The first part
only resets the handle and the second part performs native delete.
Bug: chromium:827806
Change-Id: I01eed09f94f5499cb9d13397066f4f908a0aa668
Reviewed-on: https://chromium-review.googlesource.com/995796
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52366}
In PatchTrampolineAndStubCalls, use a second iterator over the original
relocation info, to avoid having to reconstruct the original target of
the branch by manually applying the delta between the old and new code.
This way, we do not need to make assumptions regarding how code targets are
encoded.
Change-Id: I551ad8a3a654ead63ea88c8ce1d8c9e1927436b0
Reviewed-on: https://chromium-review.googlesource.com/995442
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#52365}
This reverts commit 57bf0bfefb.
Reason for revert: <INSERT REASONING HERE>
Original change's description:
> [wasm] Merge the WasmContext into WasmInstanceObject
>
> This change makes lifetime management of WasmCode much simpler.
> By using the WasmInstanceObject as the context for WASM code execution,
> including the pointer to the memory base and indirect function tables,
> this keeps the instance alive when WASM code is on the stack, since
> the instance object is passed as a parameter and spilled onto the stack.
> This is in preparation of sharing the code between instances and
> isolates.
>
> Bug: v8:7424
>
> Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
> Reviewed-on: https://chromium-review.googlesource.com/958520
> Commit-Queue: Ben Titzer <titzer@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52361}
TBR=mstarzinger@chromium.org,titzer@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I653e27b46dbc43ad773eda4292d521a508f42d79
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7424
Reviewed-on: https://chromium-review.googlesource.com/995418
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52364}
This change makes lifetime management of WasmCode much simpler.
By using the WasmInstanceObject as the context for WASM code execution,
including the pointer to the memory base and indirect function tables,
this keeps the instance alive when WASM code is on the stack, since
the instance object is passed as a parameter and spilled onto the stack.
This is in preparation of sharing the code between instances and
isolates.
Bug: v8:7424
Change-Id: Ic2e4b7bcc2feb20001d0553a615a8a9dff36317e
Reviewed-on: https://chromium-review.googlesource.com/958520
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52361}
We sometimes allow allocation to fail and return a null Handle in that
case (e.g. for grow_memory). This refactors this code to return a
MaybeHandle instead, to document that allocation might fail and to force
the caller to handle this.
R=mstarzinger@chromium.org
Change-Id: Ia3ba65f840cfb1cf93e8dbd508a17375c19bae58
Reviewed-on: https://chromium-review.googlesource.com/995438
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52358}
