Skip to content

V
V8
Switch branch/tag
  1. 01 Sep, 2020 7 commits
    • Gus Caplan's avatar
      [api] add reflection apis for v8::Data · d4d0cf32
      Gus Caplan authored 
      Allows reflection of v8::Data types, such as being able to check if a
value is a v8::Module. This is useful for libraries which wrap the V8
API, such as rusty_v8.

Change-Id: I4841c5f7f60885b20e1504c8562e278844ff7ec3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2382719Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Commit-Queue: Gus Caplan <snek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69649}
      d4d0cf32
    • Andreas Haas's avatar
      [test] Enable --wasm-tier-up when test does serialization · 10e2311f
      Andreas Haas authored 
      With a recent change, we require WebAssembly code to be tiered up to
serialize it, see https://crrev.com/c/2349290. In that CL tests were
adjusted to set the --wasm-tier-up flag when serialization was involved.
However, the test adjusted in this CL was missing, because this test
used the kExprRefNull instruction, which caused a bailout to TurboFan
anyways. With recent changes, Liftoff can compile kExprRefNull now,
and therefore causes problems.

R=thibaudm@chromium.org

Bug: v8:10852
Change-Id: I9b89f37c22f17cbf046110f3ee1c98bfea73e009
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387574Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69648}
      10e2311f
    • Peter Marshall's avatar
      [cpu-profiler] Add stats to track missing or unnattributed frames · ca6675ed
      Peter Marshall authored 
      This adds a global counter for the various reasons we might fail to
attribute a tick.

The counters are cleared and printed when Profile::Print() is called,
which we call in our tests, so flaky test output will now contain these
stats along with the printed profile tree.

Drive-by cleanup some print functions and make them const.

Change-Id: Ia3a27405f5b5346adfdbb32afc7e414857969cc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1550406
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69647}
      ca6675ed
    • evih's avatar
      [wasm] Use generic js-to-wasm wrapper for n int32 param case · 42fcb2c2
      evih authored 
      The generic wrapper can be used for Wasm functions with int32 parameters
and no return values.

Changed the GC scanning for the generic wrapper.

Added tests for cases when all the parameters of the Wasm function fit
into registers and when some of the parameters are on the top of the
stack.

Change-Id: I511fd04d2a4a2bdc4a6f72d72e2867a03b256f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381459Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Eva Herencsárová <evih@google.com>
Cr-Commit-Position: refs/heads/master@{#69645}
      42fcb2c2
    • Andreas Haas's avatar
      [wasm][fuzzer] Enable trap handlers only once · 024f2c4b
      Andreas Haas authored 
      The fuzzer function is called multiple times with libfuzzer. Trap
handlers, however, should only be initialized once. With this CL we add
a flag to initialize trap handlers only once.

R=clemensb@chromium.org

Bug: chromium:1122590
Change-Id: Ib51a50cfe9dad5e3133de3085ad147f5a069b1bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384769
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69643}
      024f2c4b
    • Peter Marshall's avatar
      Revert "[cpu-profiler] Ensure sampled thread has Isolate lock under Windows" · 32435062
      Peter Marshall authored 
      This reverts commit dfb3f7da.

Reason for revert: Breaks LSAN & ASAN flakily: https://bugs.chromium.org/p/v8/issues/detail?id=10861

Original change's description:
> [cpu-profiler] Ensure sampled thread has Isolate lock under Windows
> 
> While the sampler checked if the sampled thread had the Isolate locked
> (if locks are being used) under Linux, the check was not done under
> Windows (or Fuchsia) which meant that in a multi-threading application
> under Windows, thread locking was not checked making it prone to seg
> faults and the like as the profiler would be extracting info from a
> heap in motion. The fix was to move the lock check into CpuSampler
> and Ticker (--prof) so all OSes would do the correct check.
> 
> The basic concept is that on all operating systems a CpuProfiler, and
> so its corresponding CpuCampler, the profiler is tied to a thread.
> This is not based on first principles or anything, it's simply the
> way it works in V8, though it is a useful conceit as it makes
> visualization and interpretation of profile data much easier.
> 
> To collect a sample on a thread associated with a profiler the thread
> must be stopped for obvious reasons -- walking the stack of a running
> thread is a formula for disaster. The mechanism for stopping a thread
> is OS-specific and is done in sample.cc. There are currently three
> basic approaches, one for Linux/Unix variants, one for Windows and one
> for Fuchsia. The approaches vary as to which thread actually collects
> the sample -- under Linux the sample is actually collected on the
> (interrupted) sampled thread whereas under Fuchsia/Windows it's on
> a separate thread.
> 
> However, in a multi-threaded environment (where Locker is used), it's
> not sufficient for the sampled thread to be stopped. Because the stack
> walk involves looking in the Isolate heap, no other thread can be
> messing with the heap while the sample is collected. The only ways to
> ensure this would be to either stop all threads whenever collecting a
> sample, or to ensure that the thread being sampled holds the Isolate
> lock so prevents other threads from messing with the heap. While there
> might be something to be said for the "stop all threads" approach, the
> current approach in V8 is to only stop the sampled thread so, if in a
> multi-threaded environment, the profiler must check if the thread being
> sampled holds the Isolate lock.
> 
> Since this check must be done, independent of which thread the sample
> is being collected on (since it varies from OS to OS), the approach is
> to save the thread id of the thread to be profiled/sampled when the
> CpuSampler is instantiated (on all OSes it is instantiated on the
> sampled thread) and then check that thread id against the Isolate lock
> holder thread id before collecting a sample. If it matches, we know
> sample.cc has stop the sampled thread, one way or another, and we know
> that no other thread can mess with the heap (since the stopped thread
> holds the Isolate lock) so it's safe to walk the stack and collect data
> from the heap so the sample can be taken. It it doesn't match, we can't
> safely collect the sample so we don't.
> 
> Bug: v8:10850
> Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#69623}

TBR=akodat@rocketsoftware.com,petermarshall@chromium.org,petermarshall@google.com

Change-Id: Ib6b6dc4ce109d5aa4e504fa7c9769f5cd95ddd0c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:10850
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2387570Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69638}
      32435062
    • Santiago Aboy Solanes's avatar
      [unwinder] Clean up existing tests · 5d471ee6
      Santiago Aboy Solanes authored 
      Mostly a cleanup for x64.

Also enable two tests for Arm and Arm64 since they do not make use of
JSEntry frames.

Bug: v8:10833
Change-Id: Id6adadf582bdca0076460842ffe4ec856ca99393
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381455
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69634}
      5d471ee6
  3. 31 Aug, 2020 12 commits
    • Omer Katz's avatar
      cppgc: Update heap growing heuristics for incremental gc · aa923b1c
      Omer Katz authored 
      Heap growing estimates when to start  incremental gc such that it
will finish when we are expecting to finalize (i.e. when an atomic
gc would be triggered).
There is also a minimum ratio between limit for atomic gc and limit
for incremental gc, to guarantee that incremental gc get's some time to
run even with the application rarely allocates.

This is a continuation of:
https://chromium-review.googlesource.com/c/v8/v8/+/2377691

Bug: chromium:1056170
Change-Id: I8c87e98d60b6f8b5748558771a236f15385f7858
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381454Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69630}
      aa923b1c
    • Milad Farazmand's avatar
      PPC/s390: [wasm-simd][mips] Skip test on arch without SIMD · db837d58
      Milad Farazmand authored 
      Port 524fa743

Original Commit Message:

    This regression test does not work on MIPS without SIMD since the scalar
    lowering is not complete yet. Skip it for now.

R=zhin@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=
LOG=N

Change-Id: I0338593de3160dc0864c066e607b6030956e3efa
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2386141Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#69629}
      db837d58
    • bcoe's avatar
      [coverage] IncBlockCounter should not be side-effect · 6be2f6e2
      bcoe authored 
      Incrementing coverage counter was triggering EvalError for
evaluateOnCallFrame when throwOnSideEffect is true.

R=jgruber@chromium.org, sigurds@chromium.org, yangguo@chromium.org

Bug: v8:10856
Change-Id: I0552e19a3a14ff61a9cb626494fb4a21979d535e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384011
Commit-Queue: Benjamin Coe <bencoe@google.com>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69628}
      6be2f6e2
    • Ng Zhi An's avatar
      [wasm-simd][mips] Skip test on MIPS without SIMD · 524fa743
      Ng Zhi An authored 
      This regression test does not work on MIPS without SIMD since the scalar
lowering is not complete yet. Skip it for now.

Bug: v8:10831
Change-Id: Icc407488a96d4c965c1cf956f7a74abde078d421
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2385855Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69626}
      524fa743
    • Arthur Eubanks's avatar
      Add -Wno-string-concatenation to test/cctest:cctest_sources · 89594941
      Arthur Eubanks authored 
      v8/test/cctest/interpreter/test-bytecode-generator.cc contains lots of string arrays with intentional concatenation.

Bug: chromium:1114873
Change-Id: Ie9d35c3849b5b0a6d1d01b6ce21fb80a320d8736
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366829
Commit-Queue: Arthur Eubanks <aeubanks@google.com>
Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69625}
      89594941
    • Tianping Yang's avatar
      [test] Add a test case to the snaphot with all function code · a96715b0
      Tianping Yang authored 
      By eager compile all functions in the startup snapshot, the startup
snapshot can contain all function codes without warm-up.

BUG=v8:4836
R=yangguo@chromium.org

Change-Id: I07e86b6940c2fe75816df8ae429d110272216d0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2379535Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69624}
      a96715b0
    • Alex Kodat's avatar
      [cpu-profiler] Ensure sampled thread has Isolate lock under Windows · dfb3f7da
      Alex Kodat authored 
      While the sampler checked if the sampled thread had the Isolate locked
(if locks are being used) under Linux, the check was not done under
Windows (or Fuchsia) which meant that in a multi-threading application
under Windows, thread locking was not checked making it prone to seg
faults and the like as the profiler would be extracting info from a
heap in motion. The fix was to move the lock check into CpuSampler
and Ticker (--prof) so all OSes would do the correct check.

The basic concept is that on all operating systems a CpuProfiler, and
so its corresponding CpuCampler, the profiler is tied to a thread.
This is not based on first principles or anything, it's simply the
way it works in V8, though it is a useful conceit as it makes
visualization and interpretation of profile data much easier.

To collect a sample on a thread associated with a profiler the thread
must be stopped for obvious reasons -- walking the stack of a running
thread is a formula for disaster. The mechanism for stopping a thread
is OS-specific and is done in sample.cc. There are currently three
basic approaches, one for Linux/Unix variants, one for Windows and one
for Fuchsia. The approaches vary as to which thread actually collects
the sample -- under Linux the sample is actually collected on the
(interrupted) sampled thread whereas under Fuchsia/Windows it's on
a separate thread.

However, in a multi-threaded environment (where Locker is used), it's
not sufficient for the sampled thread to be stopped. Because the stack
walk involves looking in the Isolate heap, no other thread can be
messing with the heap while the sample is collected. The only ways to
ensure this would be to either stop all threads whenever collecting a
sample, or to ensure that the thread being sampled holds the Isolate
lock so prevents other threads from messing with the heap. While there
might be something to be said for the "stop all threads" approach, the
current approach in V8 is to only stop the sampled thread so, if in a
multi-threaded environment, the profiler must check if the thread being
sampled holds the Isolate lock.

Since this check must be done, independent of which thread the sample
is being collected on (since it varies from OS to OS), the approach is
to save the thread id of the thread to be profiled/sampled when the
CpuSampler is instantiated (on all OSes it is instantiated on the
sampled thread) and then check that thread id against the Isolate lock
holder thread id before collecting a sample. If it matches, we know
sample.cc has stop the sampled thread, one way or another, and we know
that no other thread can mess with the heap (since the stopped thread
holds the Isolate lock) so it's safe to walk the stack and collect data
from the heap so the sample can be taken. It it doesn't match, we can't
safely collect the sample so we don't.

Bug: v8:10850
Change-Id: Iab2493130b9328430d7e5f5d3cf90ad6d10b1892
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377108Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69623}
      dfb3f7da
    • Martin Bidlingmaier's avatar
      [regexp] Support some non-trivial EXPERIMENTAL patterns · 13667065
      Martin Bidlingmaier authored 
      This CL adds support for disjunctions and some quantification in
EXPERIMENTAL regexp patterns. It is implemented using a new bytecode
format and an NFA-based breadth-first interpreter.

R=jgruber@chromium.org

Bug: v8:10765
Change-Id: Idd49a3bbc9a9fcc2be80d822c9d84a638e53e777
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2370634
Commit-Queue: Martin Bidlingmaier <mbid@google.com>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69621}
      13667065
    • Jakob Gruber's avatar
      [compiler] Revisit graph end after a gasm reduction in call reducer · f8061c6c
      Jakob Gruber authored 
      The graph assembler calls MergeControlToEnd as part of Unreachable
node creation; this causes issues when used inside the GraphReducer
framework, since the reducer is not notified by gasm that the end node
should be revisited.

The (hacky) fix in this CL is to always mark the end node for
revisitation after a gasm reduction has taken place.

Bug: v8:8888,chromium:1123379
Change-Id: I350bb7144add04a0c3fd7f3d88c07fcfe1cd42e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384772
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69619}
      f8061c6c
    • Marja Hölttä's avatar
      [super property speed] Invert benchmark graphs · 925effd0
      Marja Hölttä authored 
      The goal is to have one graph per test case, and inside the graph,
4 different lines:
- baseline
- baseline noopt
- super-ic
- super-ic noopt

Bug: v8:9237
Change-Id: I511b5555487a3d96698a3fb648abf76a13f76858
No-Try: True
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2384770Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69618}
      925effd0
    • Jakob Kummerow's avatar
      [test] Make a few tests robust to GC stress · b5a33eba
      Jakob Kummerow authored 
      A recent unrelated change caused these tests to get unlucky in
GC stress mode. Their "assertOptimized" expectations rely on
certain type feedback data not getting flushed at the wrong time.

Bug: v8:10846
Change-Id: I86d0b0c049539e4a69aa764cc6ec92465ca12beb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2381458Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69617}
      b5a33eba
    • Jake Hughes's avatar
      [heap] Add object start bitmap for conservative stack scanning · 5f6aa2e5
      Jake Hughes authored 
      With conservative stack scanning enabled, a snapshot of the call stack
upon entry to GC will be used to determine part of the root-set. When
the collector walks the stack, it looks at each value and determines
whether it could be a potential on-heap object pointer. However, unlike
with Handles, these on-stack pointers aren't guaranteed to point to the
start of the object: the compiler may decide hide these pointers, and
create interior pointers in C++ frames which the GC doesn't know about.

The solution to this is to include an object start bitmap in the header
of each page. Each bit in the bitmap represents a word in the page
payload which is set when an object is allocated. This means that when
the collector finds an arbitrary potential pointer into the page, it can
walk backwards through the bitmap until it finds the relevant object's
base pointer. To prevent the bitmap becoming stale after compaction, it
is rebuilt during object sweeping.

This is experimental, and currently only works with inline allocation
disabled, and single generational collection.

Bug: v8:10614
Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195
Commit-Queue: Anton Bikineev <bikineev@chromium.org>
Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarAnton Bikineev <bikineev@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69615}
      5f6aa2e5
  5. 28 Aug, 2020 8 commits
  7. 27 Aug, 2020 5 commits
  9. 26 Aug, 2020 6 commits
  11. 25 Aug, 2020 2 commits