I incorrectly assumed that ScopeIterator::SetModuleVariableValue gets called
when the frame is the module function.
R=jgruber@chromium.org, kozyatinskiy@chromium.org
Bug: v8:1569, v8:6484
Change-Id: I1fbad8ccde57280149547c78e679527f7a0c89dd
Reviewed-on: https://chromium-review.googlesource.com/535620
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45961}
Use ICU to check ID_Start, ID_Continue and WhiteSpace even for BMP
when V8_INTL_SUPPORT is on (which is default).
Change LineTerminator::Is() to check 4 code points from
ES#sec-line-terminators instead of using tables and Lookup function.
Remove Lowercase::Is(). It's not used anywhere.
Update webkit/{ToNumber,parseFloat}.js to have the correct expectation
for U+180E and the corresponding expected files. This is a follow-up to
an earlier change ( https://codereview.chromium.org/2720953003 ).
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_win_dbg,v8_mac_dbg;master.tryserver.chromium.android:android_arm64_dbg_recipe
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_noi18n_rel_ng
BUG=v8:5370,v8:5155
TEST=unittests --gtest_filter=CharP*
TEST=webkit: ToNumber, parseFloat
TEST=test262: built-ins/Number/S9.3*, built-ins/parse{Int,Float}/S15*
TEST=test262: language/white-space/mong*
TEST=test262: built-ins/String/prototype/trim/u180e
TEST=mjsunit: whitespaces
Review-Url: https://codereview.chromium.org/2331303002
Cr-Commit-Position: refs/heads/master@{#45957}
This removes support for reconstructing stack frames for full-codegen
from the deoptimizer. We no longer deoptimize to such code. This also
allows us to remove the {DeoptimizationOutputData} data structure.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: Id28ef05aa985b6877b5c91926a7d7d0d6d6e661d
Reviewed-on: https://chromium-review.googlesource.com/535537
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45943}
This removes the ability to prepare bailout points in code generated by
the {FullCodeGenerator}. Such code is no longer used as the target of
deoptimization attempts, hence storing deoptimization data is obsolete.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: I3200182a6e88014ce953881fa0d1ac0bc65ee424
Reviewed-on: https://chromium-review.googlesource.com/533153
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45939}
For unknown Argument object Maps we have to expect that constants fields
are kept on the Map.
Bug: chromium:729597
Change-Id: I110f77455ce434a431c8de27d021b1a5deb86f30
Reviewed-on: https://chromium-review.googlesource.com/532900
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45935}
- Eliminates S32x4Shuffle, S16x8Shuffle opcodes. All shuffles are subsumed
by S8x16Shuffle. This aligns us with the latest WASM SIMD spec.
LOG=N
BUG=v8:6020
Review-Url: https://codereview.chromium.org/2923103003
Cr-Commit-Position: refs/heads/master@{#45929}
Port the baseline implementation of Object.prototype.isPrototypeOf to
the CodeStubAssembler, sharing the existing prototype chain lookup logic
with the instanceof / OrdinaryHasInstance implementation. Based on that,
do the same in TurboFan, introducing a new JSHasInPrototypeChain
operator, which encapsulates the central prototype chain walk logic.
This speeds up Object.prototype.isPrototypeOf by more than a factor of
four, so that the code
A.prototype.isPrototypeOf(a)
is now performance-wise on par with
a instanceof A
for the case where A is a regular constructor function and a is an
instance of A.
Since instanceof does more than just the fundamental prototype chain
lookup, it was discovered in Node core that O.p.isPrototypeOf would
be a more appropriate alternative for certain sanity checks, since
it's less vulnerable to monkey-patching. In addition, the Object
builtin would also avoid the performance-cliff associated with
instanceof (due to the Symbol.hasInstance hook), as for example hit
by https://github.com/nodejs/node/pull/13403#issuecomment-305915874.
The main blocker was the missing performance of isPrototypeOf, since
it was still a JS builtin backed by a runtime call.
This CL also adds more test coverage for the
Object.prototype.isPrototypeOf builtin, especially when called from
optimized code.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
BUG=v8:5269,v8:5989,v8:6483
R=jgruber@chromium.org
Review-Url: https://codereview.chromium.org/2934893002
Cr-Commit-Position: refs/heads/master@{#45925}
They were already implemented mostly in C++ (only error/negative
cases were handled in script), so this is mostly just a cleanup.
Only the constructors remain in script after this CL.
Bug: v8:6354
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5b3579337a8e33dc30d49c2da5cfd42baec697bb
Reviewed-on: https://chromium-review.googlesource.com/531670
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45924}
TracingCpuProfiler test updates the current plaform while
concurrent marking is running.
This patch also disables stress-incremental-marking for
mjsunit/regress-430201.
BUG=chromium:694255
Change-Id: I85ff538c47bce0300cde3204989ef3f9512b805f
Reviewed-on: https://chromium-review.googlesource.com/533873
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45921}
This patch also fixes several cctests that require manual GC.
BUG=chromium:694255
Change-Id: Ida93ed2498a6c5b0187ee78d2b1da27d2ff1906a
Reviewed-on: https://chromium-review.googlesource.com/533233
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45913}
The new fuzzer takes the fuzzer input as module bytes and compiles them
with WebAssembly asynchronous compilation.
R=mtrofin@chromium.org
Change-Id: I9740edec68e26c04d011d85c68521e340be13c4c
Reviewed-on: https://chromium-review.googlesource.com/506156
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45912}
The function that generated a pre-shifted immediate didn't account for the
instruction with post-shift being unencodable. Fix this by passing
information about the target instruction, and use it to limit the application
of pre-shift.
BUG=chromium:725858
Change-Id: Ia0f70b2ea057975d90162aa6889f15b553acd321
Review-Url: https://codereview.chromium.org/2922173004
Cr-Commit-Position: refs/heads/master@{#45911}
There exists a hidden assumption in V8 that neither foreground nor
background tasks own any memory. For asynchronous WebAssembly
compilation this assumption was wrong, which causes crashes when V8 shut
down before the compilation finished.
With this CL I change the way asynchrous compilation happens. In the
existing implementation each compilation stage provided its own task
which could be spawned either in foreground or background. With this CL
each stage only provides a state, and a generic CompileTask executes on
that state. There exists exactly one state at a time.
To have exactly one state at a time I combined the stages
ExecuteCompilationUnits and FinishCompilationUnits to a single stage. In
addition I removed the WaitForBackgroundTasks stage and added a
CancelableTaskManager to the AsyncCompileJob instead to do the waiting.
BUG=v8:6436
R=clemensh@chromium.org, mtrofin@chromium.org
Change-Id: I2eb61f74235c65524ce720c474eaf99ae7472c81
Reviewed-on: https://chromium-review.googlesource.com/532993
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45908}
This gives the embedder more context for deciding whether code
generation should be allowed or not, or they can chose to include the
code in a report.
BUG=chromium:732736
R=ahaas@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibbaa3d0574319d290f15565be3eed2ee4d3dda36
Reviewed-on: https://chromium-review.googlesource.com/532875
Commit-Queue: Jochen Eisinger <jochen@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45905}
This reverts commit e39c9e020f.
Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561
Original change's description:
> [compiler] Drive optimizations with feedback vector
>
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
>
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
>
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.
This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.
Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
These CL skips the tests the same way it is done on ARM.
Bug:
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I03b5b6cb2c69a4838c649ce7beee6283f3324e6d
Reviewed-on: https://chromium-review.googlesource.com/532876
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#45900}
Double element types were much slower than Smi/Object previously.
We can box each double in a HeapNumber and push them into a new
FixedArray to save going into the runtime.
Bug: v8:4826, chromium:704966
Change-Id: I7f15d0d636a52760daefed722265c696c1ebb13e
Reviewed-on: https://chromium-review.googlesource.com/531004
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45897}
With the deprecation of Crankshaft, it's no longer necessary for
FullCodeGen to keep track of its runtime profiler ticks on the code
object, and we can instead unify the behaviour of FCG and Ignition to
both increment the SFI counter instead.
Bug: v8:6408
Change-Id: Idcdd673aa39af06fe15a0fc14dfda2afafb5e417
Reviewed-on: https://chromium-review.googlesource.com/528117
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45892}
The AST-based graph builder is by now only used for asm.js code. This
change hard-codes this assumption into the compilation pipeline and
hence allows us to remove support pertaining to deoptimization from
optimized code that was not derived from bytecode.
R=jarin@chromium.org
BUG=v8:6409
Change-Id: I1138f16f663db5b9ee34e3110184067b8fcffc8b
Reviewed-on: https://chromium-review.googlesource.com/531026
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45887}
Once a buffer has been externalized, V8 is no longer responsible for managing
the memory. The fact that V8 was freeing was leading to double free errors once
Blink's GC got around to freeing the buffer too.
Bug: chromium:730171, chromium:731046
Change-Id: Ib18a7e37cafd51bce0c5a983d5cf8f3e64eb2c13
Reviewed-on: https://chromium-review.googlesource.com/530132
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45882}
This feature has been on by default without incident
since V8 5.8.
Bug: v8:5051
Change-Id: I1baf81922efd87e07448955147c50a5ba5a0aa42
Reviewed-on: https://chromium-review.googlesource.com/532214
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45881}
Avoid constructing zones and large zone objects when initializing
WasmCompilationUnit. The main reason we did that is so we can cache
the CEntryStub node, which requires a code object, obtainable only
on the main thread. We need that value, however, on background threads,
which is also where we need the aforementioned large objects. We only
need that for the WasmCompilationUnits being currently compiled, which
is a number proportional to the number of background threads provided
by the embedder. Specifically, one zone is needed only for the duration
of the background compilation, while the second zone needs to survive
past that, so the compilation results may be committed to the GC heap
as Code objects.
The problem with these large objects is that the first allocation
in a Zone is at minimum 8KB. We used to allocate 2 zones. For
modules with 200K functions, that means 3.2GB of memory pre-allocated
before any of it is actually needed.
This change attaches a Handle to the CEntryStub on the WasmCompilationUnits,
and delays zone creation to when needed. The change also adds a way to
cache CEntryStubs in a JSGraph from a given Code handle - limited to the
scenario needed by wasm (and removable once we get wasm off the GC heap,
which subsumes removing this dependency on CEntryStubs)
An additional constraint for this change is that we want it to be easily
back-mergeable to address chromium:723899.
For the wasm payload in question, collecting the max memory used by d8
using /usr/bin/time --format='(%Xtext+%Ddata %Mmax)', we get the
following numbers (in KB):
- unchanged: 3307480
- patch 1: 1807140 (45% reduction)
- patch 3: 1230320 (62% reduction from first)
- patch 5/6: 519368 (84% reduction from first)
Bug: chomium:732010, chromium:723899
Change-Id: I45b96792daf8a9c8dc47d45fb52da75945a41401
Reviewed-on: https://chromium-review.googlesource.com/530193
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45880}
- Remove commented out line
- Simulate full space properly, independently of flags set
Bug:
Change-Id: I6013caae43eb40dd568fbd872eb0ee78288c61bf
Reviewed-on: https://chromium-review.googlesource.com/531084
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45874}
Distinguish the compilation caches instead by the shape of the key (cow fixed
array map meaning eval or script cache). This allows us to remove the odd "key"
argument from Shrink, EnsureCapacity and Rehash.
Bug: v8:6474
Change-Id: Ibcad22813063c3a9050da13dc51359f5b59e1254
Reviewed-on: https://chromium-review.googlesource.com/531184
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45873}
This adds missing support for in-object properties within objects having
the {JSGeneratorObject} type to materialization during deoptimization.
For corner-cases where the implicit generator object is statically known
not to escape, object layout might still be arbitrarily complex.
R=jarin@chromium.org
TEST=mjsunit/regress/regress-crbug-732169
BUG=chromium:732169,v8:6481
Change-Id: I32f373913d60af64981dc4ed66873cc8a1dbe872
Reviewed-on: https://chromium-review.googlesource.com/530230
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45870}
The fence ensures that the concurrent marker observes consistent state
of mark-bits for newly allocated objects.
The patch also moves Bitmap functions to cc file and removes non-atomic
versions of SetRange and ClearRange.
BUG=chromium:694255
Change-Id: I466bef654f3d4a21b7aaebdfd6d5a39ddb5f2a0a
Reviewed-on: https://chromium-review.googlesource.com/530367
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45868}
console.context(name:string) method returns console instance, this console instance fully implements console interface (including fact that any method can be called without console as receiver).
Protocol.Runtime.consoleAPICalled notification contains additional context:string field:
- "anonymous#unique-id" for any method call on unnamed console context,
- "name#unique-id" for any method call on named console context.
console.count and console.timeEnd have context as a scope.
console.clear clear all messages regardless on what context instance it was called.
console calls is ~10% slower with this CL since we need to store and then fetch console_context_id and console_context_name from function object.
We recently (in April) made console calls twice faster so 10% doesn't sound critical and existing of console.log call in hot code is problem by itself.
R=pfeldman@chromium.org
Bug: chromium:728767
Change-Id: I5fc73216fb8b28bfe1e8c2c1b393ebfbe43cd02e
Reviewed-on: https://chromium-review.googlesource.com/522128
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45864}
The EnableFlagScope is useful also for non-boolean flags. With the
template we can use if for example in the wasm fuzzers to reduce the
maximum memory size of a wasm module.
In addition I put the EnableFlagScope into the v8::internal namespace,
and I fixed a small typo.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: Iae5d5c058c334cd0f9e09d20adfd229fc2d6c585
Reviewed-on: https://chromium-review.googlesource.com/531005
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45862}
In many places in WasmModule and contained structs we store references
into the wire bytes as pairs of offset and length.
This CL introduces a WireBytesRef struct which encapsulates these two
connected fields. This makes it easier to pass them and assign them as
one unit.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I4f2a40d848a51dc6f6f599f9253c3c6ed6e51627
Reviewed-on: https://chromium-review.googlesource.com/530687
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45859}
We were emitting the table index once in the element section instead of
once per element segment. This did not cause failures because we never
had more than one element segment.
This CL fixes this, and adds a test for more than one segment.
R=rossberg@chromium.org
Change-Id: I13923baf3dae383c72760286e24242d0ad55c4db
Reviewed-on: https://chromium-review.googlesource.com/527155
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45857}
This is a testing-only function, which is semantically equivalent to a
SyncCompile followed by SyncInstantiate.
We add a new SyncCompileAndInstantiate function to do those two steps
in one go, and use this method instead.
For AsmJs modules, a new testing function CompileAndRunAsmWasmModule is
introduced.
This is part of our effort to reduce the number of special paths for
testing. It is connected with
https://chromium-review.googlesource.com/529210, but should not
conflict with it.
After landing both CLs, we can later also get rid of
InstantiateModuleForTesting.
R=ahaas@chromium.org, mtrofin@chromium.org
BUG=v8:6474
Change-Id: I7891e968370d5eb68803076ce2639c65a2799dcc
Reviewed-on: https://chromium-review.googlesource.com/529844
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45852}
This CL removes unnecessary code duplication in the fuzzer code. Instead
of having special testing functions to compile and instantiate a
WebAssembly module, we now just call SyncCompile and SyncInstantiate.
This also fixed a problem when the fuzzer generated a GrowMemory
instruction.
BUG=v8:6474
R=clemensh@chromium.org
Change-Id: I5f2f23349b5866ea67be20a0826271791e1a013e
Reviewed-on: https://chromium-review.googlesource.com/529210
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45851}
