Skip to content

V
V8
Switch branch/tag
  1. 21 Mar, 2019 8 commits
    • Mike Stanton's avatar
      [turbofan] Preprocess context slots for immutable global context loads · 9b929cdc
      Mike Stanton authored 
      Main changes:
  ContextData class to hold a map of slots to ObjectData for known
    necessary lookups.
  LdaGlobal* and StaGlobal now receive an accumulator hint of the
    constant found at the lookup slot for immutable global context
    operations.

Bug: v8:7790
Change-Id: I63dc9eb8ebbbdfa4ce3b71c6aba63b3c06a3da9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532074Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60386}
      9b929cdc
    • Michael Lippautz's avatar
      heap: Fix incremental-concurrent processing of large FixedArray · c4eae87a
      Michael Lippautz authored 
      FixedArray object in LO space are processed incrementally in ranges of slots
size kProgressBarScanningChunk to reduce latency when returning to the
processing loop is critical. A progress bar stores how much slots have been
processed already.

In the case of regular concurrent marking there was a guarantee that the
object was only processed by one thread (main *or* concurrent marking
thread) at the same time.

However, some optimizations that avoid write barriers for each
individual write operation emit a batched write barrier that requires
re-visiting the FixedArray for the marking barrier. In such cases, the
progress bar would be reset using relaxed stores which is problematic as
the concurrent marking thread could race on setting its own progress on the
progress bar. As a result, the array would only be re-scanned partially.

The fix involves using CAS to set the progress bar and bail out in the
case an inconsistent state was observed.

In the following:
MT... main thread
CM... concurrent marking thread

The interesting cases are:
1. MT *or* CM processes the array without interfering: Progress bar is
   updated monotonically without failing.
3. MT interferes with itself: The progress bar is just reset and the main
   thread will restart scanning from index 0. The object is added twice to
   the marking worklist and processed each time one of the entries is
   retrieved from the worklist.
4. MT interferes with CM:
   4.a.: CM processes a range of slots and re-adds the left overs by
   setting the progress bar and re-adding the array to the worklist.  In
   this case CM *and* MT process the array from index 0. The first time
   the CAS for setting the progress bar fails on either of the threads,
   the looser will bail out and leave processing for the winner.
   4.b.: CM is interrupted while processing a range of the array and
   fails in setting the progress bar for the left overs. In this case
   the CM bails out right away and the main thread starts processing
   from index 0.

In addition, there is a transition from index 0 to the index of the
first actual slot. This transition makes it possible to observe a reset
while processing the first actual chunk of slots.

Bug: chromium:942699
Change-Id: I0b06f47ee075030dadfc959528cd77b6b69bbec2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532325Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60385}
      c4eae87a
    • Clemens Hammacher's avatar
      [wasm] Relocate code before adding it to the module · 6c44dd5f
      Clemens Hammacher authored 
      This ensures that the actual instructions are in their final form when
adding them to the NativeModule.

R=titzer@chromium.org

Change-Id: Ia20698823e5a18a3c3ef7d2370769b70addfc4e2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532075
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60384}
      6c44dd5f
    • Pierre Langlois's avatar
      [mjsunit] Do not generate compiler traces for the entire snapshot. · 2970249a
      Pierre Langlois authored 
      The `compiler-trace-flags.js` test just makes sure the various --trace-turbo*
flags do not cause V8 to crash. However, on builds with no snapshot, they would
generate a *lot* of output as they were tracing the compiler while generating
the snapshot.

Let's set the `--trace-turbo-filter` flag to make sure we only trace the test
functions. Sadly, WASM functions do not have a name, just an index, so we have
to split this test into two.

Bug: chromium:943064
Cq-Include-Trybots: luci.v8.try:v8_win_nosnap_shared_rel_ng
Change-Id: I30b3935f63d412ab8c96cc5156d342c428229865
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532078Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#60383}
      2970249a
    • Andreas Haas's avatar
      Reland: [wasm][anyref] Add support of call-indirect for multiple tables · 2d9ec0a4
      Andreas Haas authored 
      The reason for the revert was that Liftoff did not bail out on indirect
calls to tables other than table 0. Whenever the Liftoff code got
executed, the test would fail.

Original message:
With this CL it is possible to use any anyfunc table in call-indirect,
not just the first table.

The current implementation is based on runtime calls. This is just an
initial implementation which should be replaced by a
dispatch-table-based eventually. However, this implementation allows
us to move forward with the anyref proposal implementation.

R=mstarzinger@chromium.org

Bug: v8:7581
Change-Id: Iedd56ee7acb281441bca32ffd3dc7157203ee1ac
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532072
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60382}
      2d9ec0a4
    • Sigurd Schneider's avatar
      Revert "Reland "[regalloc] Introduce deferred fixed ranges"" · 21a471f2
      Sigurd Schneider authored 
      This reverts commit 1ca08865.

Reason for revert: Regressions across the board

Original change's description:
> Reland "[regalloc] Introduce deferred fixed ranges"
> 
> This is a reland of b1769313
> 
> Original change's description:
> > [regalloc] Introduce deferred fixed ranges
> > 
> > Fixed ranges are used to express register constraints in the
> > allocator. This change splits these fixed ranges into one for
> > normal code and deferred code. The former are handeled as before
> > whereas the latter are only made visible while allocating
> > registers for deferred code.
> > 
> > This prevents forward looking decisions in normal code to be
> > impacted by register constraints from deferred code.
> > 
> > Change-Id: I67d562bb41166194e62765d5ab051bc961054fc7
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1477742
> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#60322}
> 
> Change-Id: I1a31150256eb5608db985b144aab7ea457169d0d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1530810
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60364}

TBR=jarin@chromium.org,sigurds@chromium.org,herhut@chromium.org

Change-Id: Id8ad6c39774e38dd67decea997e08a4c58c452ec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1532327Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60381}
      21a471f2
    • Ben Smith's avatar
      [wasm] Call through dispatch table in interpreter · 1a88414c
      Ben Smith authored 
      When running wasm tests, the interpreter previously used a static
collection of function indexes stored in WasmTable to perform
call_indirect calls internal to that module. This has the wrong behavior
if the table is changed (via WasmTableObject::Set, `table.copy`, or
`table.init`).

This CL changes the cctests to always generate an intepreter entry for
all functions, and stores those entries in the dispatch table. This
allows us to use the same execution path as for non-testing code.

The interpreter entry compiler needed to be changed to support
multi-value returns too, since a 64-bit integer return value may be
lowered to two 32-bit integer returns.

Bug: v8:9016
Change-Id: I277df21ffde5c2eee0b691fcc9bab2b1a43eeffc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1531137
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60380}
      1a88414c
    • Frank Tang's avatar
      [Intl] Fix output of hour:'2-digit', hour12: true · fb63e5cf
      Frank Tang authored 
      Bug: chromium:527926
Change-Id: I783ba59c6e4b117163e058032fb04283e1f43c46
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1529260Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60379}
      fb63e5cf
  3. 20 Mar, 2019 32 commits