This CL refactors the WasmMemoryObject and WasmInstanceObject classes to
use WeakFixedArray instead of using a doubly-linked list of instances. This
simplifies the lifetime management of instances by not requiring them to
be unlinked from this list upon GC. It also simplifies the iteration over
the instances using a given WasmMemoryObject.
Note that, contrary to my naive assumption at the outset, it is still necessary for the InstanceFinalizer (called upon a WasmInstanceObject death) to unlink itself from a WasmMemoryObject's instances list, due to finalizer ordering.
R=deepti@chromium.org, mlippautz@chromium.org
BUG=
Review-Url: https://codereview.chromium.org/2972803002
Cr-Commit-Position: refs/heads/master@{#46482}
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}
Tsan figured out that I called compilation_units_.empty() outside a
lock.
Original message:
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: Ia83560d1c70f0802271a88c514e0d1cb0458f6c4
Reviewed-on: https://chromium-review.googlesource.com/561458
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46454}
In the original CL I moved an error check backwards, unfortunately
behind a vector lookup which should not happen when there is an error.
Now I also move the vector lookup backwards.
Original message:
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: Ie65b3cfcbcd6bdb3f04b0760673d9c7b7a0d1057
Reviewed-on: https://chromium-review.googlesource.com/561519
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46453}
This reverts commit 6c8aed76ff.
Reason for revert: Breaks some debug bots:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug/builds/16754https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/17654
Original change's description:
> [wasm] Check the size of a function body before storing it
>
> We stored the size of a function body before we check that
> these values are valid. This caused a failing DCHECK in the constructor
> of WireBytesRef which checked for integer overflows. With this CL we
> check the size of the function body before we create the WireBytesRef.
>
> R=clemensh@chromium.org
>
> Bug: chromium:738097
> Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
> Reviewed-on: https://chromium-review.googlesource.com/561000
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46442}
TBR=ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ifd533c0dee369c746bc97fea13275ebc09ed5eff
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:738097
Reviewed-on: https://chromium-review.googlesource.com/561517
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46445}
We stored the size of a function body before we check that
these values are valid. This caused a failing DCHECK in the constructor
of WireBytesRef which checked for integer overflows. With this CL we
check the size of the function body before we create the WireBytesRef.
R=clemensh@chromium.org
Bug: chromium:738097
Change-Id: I18f8b628c1499aae9c8e9340ea73c87f19e6f1d7
Reviewed-on: https://chromium-review.googlesource.com/561000
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46442}
This is a preliminary step before we stop swapping maps in the bootstrapper
(strict/sloppy map with writable prototype <-> readonly prototype).
Bug: v8:6459
Change-Id: I120550c10e98a234e283d79a8d408096601c92af
Reviewed-on: https://chromium-review.googlesource.com/558879
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46403}
When providing scope information (containing the value of local
variables of live stack frames), decode the local variable names of all
functions in a wasm module and store this in the WasmDebugInfo
structure.
Use these names to actually name the reported locals, instead of using
the default names "param#<d>" and "local#<d>". These names are only used
as fallbacks for locals which were not assigned a name.
R=titzer@chromium.org,kozyatinskiy@chromium.org
BUG=v8:6245
Change-Id: Ibf7d30e392248ef5590177cd8b6329239b45e018
Reviewed-on: https://chromium-review.googlesource.com/548495
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46379}
The `FAST_` prefix doesn’t make much sense — they’re all just different cases
with their own optimizations. Packedness being implicit (e.g. `FAST_ELEMENTS`
vs. `FAST_HOLEY_ELEMENTS`) is not ideal, either.
This patch renames the FAST elements kinds as follows:
- e.g. FAST_ELEMENTS => PACKED_ELEMENTS
- e.g. FAST_HOLEY_ELEMENTS => HOLEY_ELEMENTS
The following exceptions are left intact, for lack of a better name:
- FAST_SLOPPY_ARGUMENTS_ELEMENTS
- SLOW_SLOPPY_ARGUMENTS_ELEMENTS
- FAST_STRING_WRAPPER_ELEMENTS
- SLOW_STRING_WRAPPER_ELEMENTS
This makes it easier to reason about elements kinds, and less confusing to
explain how they’re used.
R=jkummerow@chromium.org, cbruni@chromium.org
BUG=v8:6548
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie7c6bee85583c3d84b730f7aebbd70c1efa38af9
Reviewed-on: https://chromium-review.googlesource.com/556032
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46361}
This reverts commit 1520a8518a.
Reason for revert: This CL does not do what it should. All tasks which access the isolate have to be cancelable to guarantee that the isolate still exists when the task is executed. Foreground compilation tasks access the isolate, so they cannot be just normal tasks.
Original change's description:
> [wasm] Run foreground compilation tasks as normal tasks
>
> This CL makes foreground compilation tasks normal (i.e. not cancelable)
> again, because otherwise a deadlock can happen. I think the reason why
> the foreground tasks were cancelable was to make sure that all tasks
> either finish correctly or get canceled. However, since the isolate can
> only shut down on the main thread, this means that the foreground task
> should have already finished when the isolate shuts down, or it should
> not have started at all. I reordered the deletion of the AsyncCompileJob
> though to make sure that an AsyncCompileJob is removed from
> CompilationManager before its promise is resolved.
>
> Here is the deadlock: The JS code which is executed after a promise is
> resolved is executed within the task which resolves the promise. In case
> of async compilation this means that some JS code is executed within a
> CompileTask. In JS, the shutdown of the isolate can be triggered. During
> the shutdown of the isolate, the CancelableTaskManager waits for all
> registered cancelable tasks to complete, including the CompileTask of
> async compilation. This means that the CancelableTaskManager waits for
> itself to finish, which is a deadlock.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
> Reviewed-on: https://chromium-review.googlesource.com/554733
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46343}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: I60fab90b46d70c703d827816503e7e23b8c50251
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558284
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46353}
This reverts commit ca93156294.
Reason for revert: tsan:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/16007
Original change's description:
> [wasm] Allow the initialization of a single compilation unit
>
> This CL adds a new function {InitializeCompilationUnit} to initialize
> a single compilation unit and not just all compilation units at once.
> This is necessary for streaming compilation eventually. This also
> required some refactoring on how the working queue for compilation units
> works. Previously the synchronization was done with an atomic counter,
> now it is done with a lock. Note that the code to finish compilation
> of a module still only works if the working queue gets only empty when
> all work is done. I plan to change this in a different CL.
>
> Since the code would not be tested without streaming compilation, I added
> an experimental flag and a test to test the new code.
>
> R=clemensh@chromium.org, mtrofin@chromium.org
>
> Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
> Reviewed-on: https://chromium-review.googlesource.com/550096
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46348}
TBR=mtrofin@chromium.org,ahaas@chromium.org,clemensh@chromium.org
Change-Id: Ied6532f05463c0b78c8b8f5307d44640bcca8316
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/558224
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46350}
This CL adds a new function {InitializeCompilationUnit} to initialize
a single compilation unit and not just all compilation units at once.
This is necessary for streaming compilation eventually. This also
required some refactoring on how the working queue for compilation units
works. Previously the synchronization was done with an atomic counter,
now it is done with a lock. Note that the code to finish compilation
of a module still only works if the working queue gets only empty when
all work is done. I plan to change this in a different CL.
Since the code would not be tested without streaming compilation, I added
an experimental flag and a test to test the new code.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I839c04fd78d1ea8e1db202f2cbed41c4c2cf4f28
Reviewed-on: https://chromium-review.googlesource.com/550096
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46348}
This CL makes foreground compilation tasks normal (i.e. not cancelable)
again, because otherwise a deadlock can happen. I think the reason why
the foreground tasks were cancelable was to make sure that all tasks
either finish correctly or get canceled. However, since the isolate can
only shut down on the main thread, this means that the foreground task
should have already finished when the isolate shuts down, or it should
not have started at all. I reordered the deletion of the AsyncCompileJob
though to make sure that an AsyncCompileJob is removed from
CompilationManager before its promise is resolved.
Here is the deadlock: The JS code which is executed after a promise is
resolved is executed within the task which resolves the promise. In case
of async compilation this means that some JS code is executed within a
CompileTask. In JS, the shutdown of the isolate can be triggered. During
the shutdown of the isolate, the CancelableTaskManager waits for all
registered cancelable tasks to complete, including the CompileTask of
async compilation. This means that the CancelableTaskManager waits for
itself to finish, which is a deadlock.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I9f8c7fb2cfc5b9bfc53c761010b1590293bb82c9
Reviewed-on: https://chromium-review.googlesource.com/554733
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46343}
The naming convention in v8 has trivial getters named like the field,
no 'get_' prefix, and dropping the '_' suffix of the field.
BUG=
Review-Url: https://codereview.chromium.org/2958283003
Cr-Commit-Position: refs/heads/master@{#46332}
In our internal code, we should only use pending exceptions. They will
be converted to scheduled exceptions on the API boundary.
Hence, the ErrorThrower just sets a pending exception; it should never
have to think about scheduled exceptions. The new
ScheduledErrorThrower inherits from ErrorThrower and reschedules any
pending exceptions in its destructor (turning them into scheduled
exceptions).
In some situations, there might already be a scheduled exception, e.g.
when calling other API methods (v8::Value::Get). In this case, the
ErrorThrower should also not set another pending exception. For the
reasons mentioned above, this can only be handled in the
ScheduledErrorThrower, which is used the API methods.
This fixes one DCHECK failure and one TODO about scheduled exceptions
if no instance can be created, because the start function throws.
R=mtrofin@chromium.org, mstarzinger@chromium.org
BUG=v8:6232,chromium:736256
Change-Id: I4905be04c565df9495de18fb26adbb5c05d193d2
Reviewed-on: https://chromium-review.googlesource.com/548641
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46314}
Removes from CL https://codereview.chromium.org/2929853003 code to fix
histogram timers in class WasmCompilationUnit. This was done because
the CL was reverted due to errors caused by background compiles that
updated UMA histogram timers.
The goal of this CL is to reland the remaining portion of the reverted
CL.
Bug:v8:6361
Change-Id: Ic03ceb118734bd55c463a843521bcd5b09342afe
Reviewed-on: https://chromium-review.googlesource.com/550196
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Karl Schimpf <kschimpf@google.com>
Cr-Commit-Position: refs/heads/master@{#46268}
This makes reopening the handle easier, and also reduces the size of
the handle space.
Drive-by change: Make all fields of the ModuleCompiler private.
R=clemensh@chromium.org
Change-Id: I2f9553a00012b9ce7743bf68bdf1c3095ca69fe0
Reviewed-on: https://chromium-review.googlesource.com/548397
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46255}
If a String object contains unicode, the returned {ToCString()} may
actually longer than the {length()} of the String.
But it's always null-terminated, so we can just print it without
explicitly passing a length.
R=ahaas@chromium.org
Change-Id: I3398f151d70ed459ecd8093ea18409670a7374c7
Reviewed-on: https://chromium-review.googlesource.com/548058
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46225}
The implication was actually in the wrong direction: If there is no
memory start address, then the size must be 0.
If the size is 0 though, we might allocate nevertheless to have guard
pages around the accessible memory.
R=ahaas@chromium.org
BUG=chromium:736584
Change-Id: I297dece658d5eaf69c58ecb109ff21d3ca0b8a8d
Reviewed-on: https://chromium-review.googlesource.com/548635
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46221}
Test that unicode identifiers can be used for imports and exports, and
that unicode function names appear correctly in error messages.
R=ahaas@chromium.org
Change-Id: Ic6ac77159c275845886b2eb779cf59edb8cba9ea
Reviewed-on: https://chromium-review.googlesource.com/548315
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46220}
Instead of calling {TryAllocateBackingStore} with
{enable_guard_regions==false}, we just directly call
{array_buffer_allocator->Allocate}.
Drive-by optimization: Don't allocate if the size is 0.
R=titzer@chromium.org
Change-Id: Iabf7af7e0f1bc970c03efcd9ee4c23e5307a7095
Reviewed-on: https://chromium-review.googlesource.com/548398
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46218}
The only difference between GetNextUncompiledFunctionId +
CompileAndSchedule and FetchAndExecuteCompilationUnit is that
FetchAndExecuteCompilationUnit potentially calls a callback if
it detects that no finishing task is executing. With this CL
I replace the two functions again with
FetchAndExecuteCompilationUnit. I add a flag so that no callback
is called when the flag is not set. If no callback is called,
FetchAndExecuteCompilationUnit behaves exactly the same
as the other two functions together.
R=clemensh@chromium.org
Change-Id: I17318381eec2d17b13d0902984f2620b909c7ea0
Reviewed-on: https://chromium-review.googlesource.com/544954
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46210}
This is a fix to https://codereview.chromium.org/2929853003 that got
reverted. The DCHECK checked to see that it was not in a background
thread. While this is a property we want for v8, it is also used
by blink, and blink violates this property.
Therefore, this CL removes the DCHECK for now.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2961443002
Cr-Commit-Position: refs/heads/master@{#46190}
For correct error positions, the FunctionBody struct stored a {base}
pointer to the beginning of the wasm module bytes, in addition to the
{start} and {end} pointer of the function body within the module bytes.
For streaming compilation, we do not have all module bytes in a single
chunk of memory. Therefore this CL changes the FunctionBody such that it
does not store the base pointer but the offset of the function body
within the module. I did the same change already some time ago for the
{Decoder}.
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I5138fbe270d0f5166a7dcc5cb8f3fe78a298bff6
Reviewed-on: https://chromium-review.googlesource.com/544863
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46170}
HistoryTimer's can't run in the background because they use a timer
with a simple api of Start() and Stop(). This CL fixes this problem
by building a base class TimedHistogram that doesn't have a timer.
The class HistoryTimer is modified to use this base class so that
uses that run on the foreground thread do not need to be modified.
It also adds a new class TimedHistogramScope that defines the timer
in this class. This allows the corresopnding TimedHistogram class to
be type safe.
BUG=v8:6361
Review-Url: https://codereview.chromium.org/2929853003
Cr-Commit-Position: refs/heads/master@{#46150}
This CL does same changes as
https://chromium-review.googlesource.com/c/540763/, but for async
compilation instead of for parallel compilation. The biggest difference
is that for async compilation I start background tasks again when half
of the memory is free again and not when all the memory is free again.
Original description:
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
The change avoids blocking the background threads while we're over the
memory threshold. This is to avoid starving the GC.
R=mtrofin@chromium.org
Change-Id: I7399e2474f72f6727e6e50176dd7ba95cdcd3238
Reviewed-on: https://chromium-review.googlesource.com/543477
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46120}
This was left over from the previous CL to change S128LoadMem/S128StoreMem to
use prefixed opcodes. Decoding prefixed opcodes already checks for the
prototype flag.
BUG=V8:6020
R=bbudge@chromium.org
Review-Url: https://codereview.chromium.org/2946303002
Cr-Commit-Position: refs/heads/master@{#46108}
On an error during {ProcessExports()}, we would just continue
execution, resulting in a DCHECK failure later.
I did not find any tests for exported globals, so I added a few
(including a regression test for the referenced bug).
R=ahaas@chromium.org
BUG=chromium:734295
Change-Id: I35370de934c274f870680c662ef848c72268a7bc
Reviewed-on: https://chromium-review.googlesource.com/539401
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46064}
If one wasm instance imports an exported function of another instance,
we unwrap the js-to-wasm wrapper of the export and use the underlying
code object directly. However, the code object does not keep the wasm
instance alive. It is only connected via a WeakCell.
With this CL, we explicitly store a FixedArray of all wasm instances
from which we imported functions to keep them alive at least as long as
the instance which imports the code.
R=mtrofin@chromium.org, ahaas@chromium.org
BUG=chromium:734345
Change-Id: I8dcfc9a4ea2d791a62d8cb7255039e481c50bdfd
Reviewed-on: https://chromium-review.googlesource.com/539738
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46062}
This makes sure that the coercion of global import values to numbers
remains non-observable to JavaScript. It allows instantiation failures
to fall back to JavaScript proper without accidentally causing some
side-effect to happen twice. Also coercions might invalidate previous
checks done during linking or throw exceptions.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6431
BUG=v8:6431
Change-Id: Ibe2f7a336bc0fb25532d526746ecc802e04bbd5c
Reviewed-on: https://chromium-review.googlesource.com/512544
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46051}
The constructor of WireBytesRef checks that offset+length is still in
the uint32_t range. This CL avoids triggering this check on illegally
size strings.
R=ahaas@chromium.org
BUG=chromium:734246
Change-Id: Iab5c7013aa3e0ac5060bc4733e712a1652679b1a
Reviewed-on: https://chromium-review.googlesource.com/539402
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46050}
https://codereview.chromium.org/2632713003 with workaround for old GCC.
Drive-by: fix unused variable in src/wasm/wasm-js.cc
Bug:chromium:457078
Change-Id: I6c1b65076bae783c31869552bc87d05c28550e26
Reviewed-on: https://chromium-review.googlesource.com/538463
Commit-Queue: Loo Rong Jie <loorongjie@gmail.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46049}
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
The change avoids blocking the background threads while we're over
the memory threshold. This is to avoid starving the GC.
Bug: v8:6492, chromium:732010
Change-Id: Ic2647d9fa71af4f8cdd2149a434b107cbed3a6c3
Reviewed-on: https://chromium-review.googlesource.com/540763
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46029}
This reverts commit 1835b4b177.
Reason for revert: This has a perf regression, wasn't ready just yet.
Original change's description:
> Revert "Revert "[wasm] Throttle the amount of unfinished work to avoid OOM""
>
> This reverts commit 4ee4918195.
>
> Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
>
> Original change's description:
> > Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
> >
> > This reverts commit 1280954d3a.
> >
> > Reason for revert: Speculative, GC stress bots started taking much longer after this change.
> >
> > Original change's description:
> > > [wasm] Throttle the amount of unfinished work to avoid OOM
> > >
> > > It is possible that the foreground task is unable to clear the
> > > scheduled unfinished work, eventually leading to an OOM.
> > >
> > > We use either code_range on 64 bit, or the capacity of the code space,
> > > as a heuristic for how much memory to use for compilation.
> > >
> > > Bug: v8:6492, chromium:732010
> > > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > > Reviewed-on: https://chromium-review.googlesource.com/535017
> > > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#46017}
> >
> > TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
> >
> > Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> > No-Presubmit: true
> > No-Tree-Checks: true
> > No-Try: true
> > Bug: v8:6492, chromium:732010
> > Reviewed-on: https://chromium-review.googlesource.com/540270
> > Reviewed-by: Bill Budge <bbudge@chromium.org>
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46020}
>
> TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540841
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46022}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,mtrofin@google.com,ahaas@chromium.org
Change-Id: Ic1351325173b233be3972ff3c159c035838fa963
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540842
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46023}
This reverts commit 4ee4918195.
Reason for revert: Fix: in d8, blocking all the bg threads starves the GC.
Original change's description:
> Revert "[wasm] Throttle the amount of unfinished work to avoid OOM"
>
> This reverts commit 1280954d3a.
>
> Reason for revert: Speculative, GC stress bots started taking much longer after this change.
>
> Original change's description:
> > [wasm] Throttle the amount of unfinished work to avoid OOM
> >
> > It is possible that the foreground task is unable to clear the
> > scheduled unfinished work, eventually leading to an OOM.
> >
> > We use either code_range on 64 bit, or the capacity of the code space,
> > as a heuristic for how much memory to use for compilation.
> >
> > Bug: v8:6492, chromium:732010
> > Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> > Reviewed-on: https://chromium-review.googlesource.com/535017
> > Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#46017}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
>
> Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: v8:6492, chromium:732010
> Reviewed-on: https://chromium-review.googlesource.com/540270
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46020}
TBR=bradnelson@chromium.org,bbudge@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I1e7a1d0202c3161f9a7139e8895eebf472473ad3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540841
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46022}
This reverts commit 1280954d3a.
Reason for revert: Speculative, GC stress bots started taking much longer after this change.
Original change's description:
> [wasm] Throttle the amount of unfinished work to avoid OOM
>
> It is possible that the foreground task is unable to clear the
> scheduled unfinished work, eventually leading to an OOM.
>
> We use either code_range on 64 bit, or the capacity of the code space,
> as a heuristic for how much memory to use for compilation.
>
> Bug: v8:6492, chromium:732010
> Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
> Reviewed-on: https://chromium-review.googlesource.com/535017
> Commit-Queue: Brad Nelson <bradnelson@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46017}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,ahaas@chromium.org
Change-Id: I8883cee7f77667530bc50f91bfb468c485e6f7f2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6492, chromium:732010
Reviewed-on: https://chromium-review.googlesource.com/540270
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46020}
It is possible that the foreground task is unable to clear the
scheduled unfinished work, eventually leading to an OOM.
We use either code_range on 64 bit, or the capacity of the code space,
as a heuristic for how much memory to use for compilation.
Bug: v8:6492, chromium:732010
Change-Id: I1e4c0825351a42fa0b8369ccc41800ac3445563d
Reviewed-on: https://chromium-review.googlesource.com/535017
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46017}
- Use correct prefixes for SIMD/Atomics ops
- S128 LoadMem/StoreMem should not use 0xc0/0xc1 opcodes, these are now
being used for sign extension
- S128 LoadMem/StoreMem should use prefixed opcodes
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2943773002
Cr-Commit-Position: refs/heads/master@{#46016}
For functions without any calls, there is no value in executing a stack
check. The current frame is materialized at that point anyway.
Note that for loops, we still emit additional stack checks in the loop
header.
For unity, the reduction in code size is moderate (0.53%), as only 4000
of the 34000 functions are leaf functions (no calls). However, we also
save some compile time and gain performance, so this is still worth
doing it.
Drive-by: Fix the effect chain generated in {StackCheck()}.
R=mstarzinger@chromium.org, ahaas@chromium.org
Change-Id: Ia6ec58d0ea46de02634c923cdf8e6e08d8902c59
Reviewed-on: https://chromium-review.googlesource.com/533333
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46013}
