Generate the test case before compilation, so that we can generate it
even if compilation crashes.
We can only do this when require_valid is true. Otherwise the test case
depends on whether the module compiles or not.
R=ahaas@chromium.org
CC=khismet@google.com
Bug: v8:11954
Change-Id: I944e867cc7ca631bff749bd67c4b8baff1df1fa9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074476
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76123}
If no GC happens when we grow the assembler buffer (this could happen
since we allocate a new Code object), we do not need to fix references
to full-embedded-objects.
Bug: v8:11872
Change-Id: I11fb1abcb4c53e124bb7659c9f9995ccb18cf296
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3073741
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76122}
Bug: v8:7790
Change-Id: Ia5903364a774bd49db1a646b3066b9972deac725
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074465
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76119}
Bug: v8:7790
Change-Id: I299678102254ffb7d68be3d5cad11b4a4161492f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068947
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76118}
Forgot to do this in crrev.com/c/3067226.
Bug: v8:7790,v8:12030
Change-Id: Ic6fbf3feb07e8d08f0fd83d76d54535387c7a27c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074464
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76117}
This CL limits the amount of address space we reserve for shared
WebAssembly memory. Up until now we just reserved either the defined
maximum size of the memory or the V8-defined maximum memory size,
depending on whether the maximum size is defined or not. This could
cause OOMs easily on 32-bit systems due to address space exhaustion.
With this CL we limit the amount of address space we reserve for shared
WebAssembly memory.
1) We try to reserve at least the initial size;
2) If no maximum size is defined, we reserve 1GB by default;
3) If a maximum size is defined, then we reserve that maximum size
but at most 1GB.
Note that the handling of shared memory here is different than the
handling of not-shared memory because for shared memory it is not
possible to grow with realloc.
R=clemensb@chromium.org
Bug: v8:12038
Change-Id: I00493b330ee00588d65cbffa6f042e039106736e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071206
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76116}
There was a DCHECK to ensure tests don't miss enabling either bytecode
or baseline code flushing along with stress-flush-code. Fuzzers use
different combination of flags so there we should allow
stress-flush-code without bytecode / baseline code flushing.
Bug: chromium:1236614,v8:11947
Change-Id: I86190b6336015e37288cffffc05de2fa21f496ad
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074462
Commit-Queue: Mythri Alle <mythria@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76115}
Optimizing compilation can no longer collect source positions on demand
since it may now run concurrently without serialization.
Instead, we now collect full source positions when any component that
needs them is enabled (profiler, debugger).
Bug: v8:7790,v8:12030
Change-Id: I6a2a82eb2b0d3e92121e101b4d9bf330c1f6c065
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067226
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76114}
ObjectDataKind::kSerializedHeapObject is no longer in use.
Remove the CreateDataFunctors since creation code is now simple
and uniform enough to inline.
Bug: v8:7790
Change-Id: I90009373b4f6b5e1b0ed90c7ccff323dc9821ed8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3073740
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76113}
Skip over SFIs that already have source position available.
Bug: v8:7790
Change-Id: Iaea51fe1e4cec9e3291a258a1c60b2354afa8525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3074239
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76112}
This CL fixes a long standing issue where reentering TimedHistograms
scopes would cause spurious measurements. Only the non-nested scopes
yielded correct results.
Due to the changed numbers, the V8.Execute histogram is renamed to
V8.ExecuteMicroSeconds. Note that this histogram is also guarded
behind the --slow-histograms flag due to the additional overhead.
Unlike before, it does no longer include time for external callbacks
and only measures self time. The following example illustrates the
new behaviour:
1. Enter V8: |--+.......+--| self-time: 4 units (reported)
2. Exit V8 (callback): |-+...+-| self-time: 2 units (ignored)
3. Re-enter V8: |---| self-time: 3 units (reported)
This would result in 2 histogram entries with 4 time units for the first
V8 slice and 3 units for the nested part. Note that the callback time
itself is ignored.
This CL attempts to clean up how TimedHistograms work:
- Histogram: the base class
- TimedHistograms: used for time-related histograms that are not nested
- NestedTimeHistograms: Extends TimedHistograms and is used for nested
histograms
This CL changes Histograms to not measure time themselves. Measurements
happen in the *HistogramScopes:
- BaseTimedHistogramScope: Base functionality
- TimedHistogramScope: For non-nested measurements
- NestedTimedHistogramScope: For nested measurements
- PauseNestedTimedHistogramScope: Ignore time during a given scope.
This is used to pause timers during callbacks.
Additional changes:
- ExternalCallbackScope now contains a PauseNestedTimedHistogramScope
and always sets VMState<EXTERNAL>
Bug: v8:11946
Change-Id: I45e4b7ff77b5948b605dd50539044cb26222fa21
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3001345
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76111}
It was missing an AssumeMemoryFence.
Bug: v8:7790,chromium:1236612
Change-Id: Icd3ed9f9979b0ba287c9dff7f4f8722ac06e859a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3073739
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76110}
Just re-use the error constructor's initial map for the
WebAssembly.Exception constructor, instead of creating a new one.
R=jkummerow@chromium.org
Bug: v8:11992
Change-Id: If1ee53a1e9492c9ab4b59e363b388260ff097cf5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071211
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76108}
For streaming compilation, scripts don't have a source string attached
until finalization, but the Script and SharedFunctionInfo objects are
already on the heap and may be picked up by heap walks.
This happens e.g. in CollectSourcePositionsForAllBytecodeArrays, where
we then try to reparse and recompile the SFI. This is invalid, since
the source string is not yet set.
Avoid this by checking for the empty source string (and leaving a TODO
for a nicer future solution).
Bug: v8:12051
Change-Id: Ib4f40cd218151120e5aff8558dd5df5c8834412e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071403
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76104}
Rolling v8/build: cff8a26..e360729
Rolling v8/third_party/aemu-linux-x64: DxCnfY154Xn-UYrZ-GF8FewyGfo29cYHkKdDMgpEHJkC..Nw0OOp4j9l4Sj0WpOmaRhNeJ137UfsLg0P1YrF8uzKwC
Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/61f0e50..cb61e19
Rolling v8/third_party/depot_tools: a806594..0a4dd41
Rolling v8/third_party/icu: 2a822c5..75e34bc
Rolling v8/tools/luci-go: git_revision:db421da12bad8e57f97ee45b24147e34ec882007..git_revision:467ab48f5ed9f3ef32ae17f5b73a117e0c86566b
Rolling v8/tools/luci-go: git_revision:db421da12bad8e57f97ee45b24147e34ec882007..git_revision:467ab48f5ed9f3ef32ae17f5b73a117e0c86566b
Rolling v8/tools/luci-go: git_revision:db421da12bad8e57f97ee45b24147e34ec882007..git_revision:467ab48f5ed9f3ef32ae17f5b73a117e0c86566b
TBR=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com
Change-Id: I4006df2bfd8824d5a680d0c24b39f5b4a29f11b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071613
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#76101}
The number of arguments for the LiftoffCompiler has grown significantly
since its initial implementation, and it becomes hard to keep track of
all options at the call sites.
This CL refactors all optional parameters into a {LiftoffOptions} struct
which has a factory-like interface.
This will allow us to add more options in the future, e.g. for dynamic
tiering.
R=thibaudm@chromium.org
Change-Id: I66697bb2f99b676a84c158304cc3a285e1b077d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069148
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76098}
For inline scripts that have a `// #sourceURL=foo.js` annotation, the
V8 inspector (and by extension `Error.stack`) currently operates in
terms of the `foo.js`, i.e. doesn't give any hint about the actual
source, except for the line/column offsets reported upon scriptParsed.
However in case of stack frames (i.e. as part of `Error.stack` or as
part of the call frames reported via CDP), the line/column offsets are
relative to the actual source instead of relative to the `foo.js` part,
which - besides other things - makes post-processing of recorded stack
traces tricky (sometimes impossible).
This change adjusts the source positions reported for (inline) scripts
with sourceURL annotations to be relative to the (inline) script instead
of the surrounding document.
Bug: chromium:1183990
Fixed: chromium:578269
Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76097}
This CL is a port of https://crrev.com/c/3045349 for ia32 and arm,
adding helper methods to drop arguments from the stack.
Drive-by: Add RootAsOperand to ia32.
Bug: v8:11112
Change-Id: I07b753d51b9fc9fc91bf09618b1315d146827123
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069157
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76095}
crrev.com/c/3069146 fixed a write barrier issue leading to a null
dereference on Windows that was triggered by having the stack allocated
at address below 4GB.
Turns out the same can happen on Fuchsia.
Bug: chromium:1230763, chromium:1056170
Change-Id: I74ba0b465c3230b4274f2c23d279c4f73183eddb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071402
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Auto-Submit: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76094}
For some reason, the "ret" instruction goes missing on Mac release
builds, probably because the compiler decides to split the inline
assembly block and move the "v8_probe_memory_continuation" block
somewhere else. This CL fixes that by adding another explicit "ret" at
the end of "ProbeMemory".
Also, we remove the "v8_probe_memory_address" symbol (which is identical
to just "ProbeMemory"), to prevent the compiler from splitting
"ProbeMemory" and "v8_probe_memory_address".
R=ahaas@chromium.org
Bug: v8:11955
Change-Id: I2e63b2db94206e329be214ab7b553ab502d6ecc2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071202
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76091}
Maximum frame size (in bytes) is used to check for stack overflows
in the prologue.
The maximum number of call arguments is pre-calculated and included
in this check. However the count was added to the frame size wihout
converting the count to bytes, resulting in inaccurate stack overflow
checks.
Bug: chromium:1235182
Change-Id: I21bca4e183fccfd055f2f1d5a40b71651c14b911
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3071399
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Patrick Thier <pthier@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76090}
Convert more raw Handle<Map> uses to MapRef.
Bug: v8:7790
Change-Id: Id638b70607aa5a73404ee37dfda5e038018be525
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067337
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76089}
In crrev.com/c/3056970 I merged reporting allocated bytes from CppHeap
to v8 with reporting from cppgc to CppHeap. The reporting handler
assumed in_no_gc_scope() is false.
Unfortunately this breaks. On heap termination, cppgc will report to
CppHeap but CppHeap will have entered a no gc scope when it detached
from the isolate.
We could adjust the DCHECK, but I think it's simpler to revert to the
previous unmerged state and simply port the bug fix from
crrev.com/c/3056970 (i.e. lines 484-486 in cpp-heap.cc in this CL).
Bug: chromium:1056170
Change-Id: I5aa953c31388f7b3bb3326ff10d5a33961be2aa1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067227
Reviewed-by: Anton Bikineev <bikineev@chromium.org>
Commit-Queue: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76088}
The merge values of a block have to be initialized to their
static types, even if the actual values on the stack have
subtypes of the loop's static type.
Drive-by cleanup: drop some unneeded manual {TestModuleBuilder}
instantiations from existing tests. The test fixture provides
one anyway.
Bug: chromium:1234453
Change-Id: I39c7eae4b6a6d5124f29be92da5ee92ff7e20e57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068948
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76087}
This is a reland of ce8cef36aa
Original change's description:
> [inspector] Consistently format all native accessors as own properties.
>
> Previously the V8 inspector would only turn embedder accessors on the
> prototype chain into data properties, but would not do the same for
> ECMAScript builtins, which is kind of inconsistent and weird behavior.
>
> This leaves in the hack that the inspector reports native accessor
> properties as (own) data properties, but now at least the very least
> does so consistently. In the absence of a better solution, we'll go
> with this for now.
>
> Bug: chromium:1076820, chromium:1199247
> Change-Id: I593f909a46cb714dbec629a2944eeb892881ba6f
> Before: https://imgur.com/kPuSldj.png
> After: https://imgur.com/eFau45m.png
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3067319
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#76059}
Bug: chromium:1076820, chromium:1199247
Change-Id: I11987194b0d0b8b250eda4f8ce0ae5fc743eb27c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070701
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Kim-Anh Tran <kimanh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76084}
We can avoid the scratch register by directly using the operand in the
"sub" instruction.
R=victorgomes@chromium.org
Bug: v8:12017
Change-Id: Ib1768a92b0ef98bf7dbed522f467eff395d08e8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069138
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76082}
git secrets keeps complaining that the previous string was a
possible credential. This patch changes it to be less like a
credential and removes the annoying warning.
Change-Id: I5074a4e3c11ab0d689b1a88e8d3eec0794dad899
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070699
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76081}
The field is immutable after initialization and thus should be set
non-atomically on the main thread, and read non-atomically on the
background thread. But TSAN support for generated code turns all field
accesses into relaxed atomic accesses, leading to this race detection.
Silence it by making the read relaxed as well.
Bug: chromium:1236302,v8:7790
Change-Id: I47979b2dbf61a65a9e92453324fe2b255fafd30d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070700
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76080}
These should be reenabled when the underlying issue is fixed.
Bug: v8:7790,v8:12031
Change-Id: Id950cceaa10209b17c2857d61183a2394638d6fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3068951
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76078}
.. when not concurrent-inlining.
These were accidentally removed for all configurations, but should
have been removed only for --concurrent-inlining.
Removed in crrev.com/c/3059683.
Bug: v8:7790,chromium:1236298
Change-Id: I39695a515b87139f0b1bf3e247e3038146a7d754
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069154
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76076}
Add support to flush only baseline code. FLAG_flush_baseline_code
controls if baseline code is flushed or not and FLAG_flush_bytecode
controls if bytecode is flushed or not. With this CL it is possible
to control if we want to flush only bytecode / only baseline code / both.
This also lets us have different heuristics for bytecode and baseline
code flushing.
Bug: v8:11947
Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76075}
Invalid ref construction (should assume a memory fence), and invalid
unconditional use of an optional ref.
Bug: v8:7790,chromium:1236303,chromium:1236307
Change-Id: Id0a12222d3d29a0728290ad5269da0946647a5ca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070698
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76074}
