Skip to content

V
V8
Switch branch/tag
  1. 29 Jul, 2022 31 commits
  3. 28 Jul, 2022 9 commits
    • Milad Fa's avatar
      PPC [liftoff]: Implement simd replace lane ops · c373fc7b
      Milad Fa authored 
      Change-Id: I4bbe5be6c6f13ee5664fa231d8dd9d59aa0ef579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792166Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82051}
      c373fc7b
    • Frank Tang's avatar
      Reland "[test262] Roll test262" · cd1a6e73
      Frank Tang authored 
      This is a reland of commit 33043888

Original change's description:
> [test262] Roll test262
>
> https://chromium.googlesource.com/external/github.com/tc39/test262/+log/3ddfa0cd..e41d581c
>
> Bug: v8:7834
> Change-Id: Id1c5b07f109ab6f60498eb7185becc508d16af1e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3786907
> Reviewed-by: Shu-yu Guo <syg@chromium.org>
> Commit-Queue: Frank Tang <ftang@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#81980}

Bug: v8:7834
Change-Id: Ic7e0378b11a05161b69965cff06985b9a2d954fe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788719Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82050}
      cd1a6e73
    • Frank Tang's avatar
      [intl] Ship Intl NumberFormat v3 · 3f96776a
      Frank Tang authored 
      Also need to change how we got the prototype of Intl.NumberFormat
and Intl.PluralRules to install function in bootstrapper.cc code to avoid assertion in JSReceiver casting.

For m106
Flag: harmony_intl_number_format_v3
https://chromestatus.com/feature/5707621009981440
Design doc:
https://docs.google.com/document/d/19jAogPBb6W4Samt8NWGZKu47iv0_KoQhBvLgQH3xvr8
and
https://docs.google.com/document/d/14zxGub6Os6nARzH6XstOZX05w2537sZo_ZSSlGjGpBM

R2T: https://groups.google.com/a/chromium.org/g/blink-dev/c/vy6rCuh3r_0/m/1Q2FHx9hBAAJ
I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/mN6o7uk2hjM/m/I6-C006lBwAJ
LGTMs from API Owners: bratell.d@gmail.com, miketaylr@chromium.org, mkwst@chromium.org

Bug: v8:10776
Change-Id: I2c11e1c53390bdc6246caf084661d82e08a4d94c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3790120
Commit-Queue: Frank Tang <ftang@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82049}
      3f96776a
    • Manos Koukoutos's avatar
      [wasm-gc] All type shorthands should be nullable · 387dfe27
      Manos Koukoutos authored 
      arrayref, dataref and i31ref get changed to (ref null t).

Bug: v8:7748
Change-Id: Iae0e6969a1f71ccf1f193c267d761b7a1796f67b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788093
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82048}
      387dfe27
    • Etienne Pierre-doray's avatar
      [gc] Use CreateJob().Join() in v8 gc to avoid extra context switches · a2993308
      Etienne Pierre-doray authored 
      CreateJob() doesn't schedule anything until Join() or Notify*() is called. CreateJob().Join() will thus schedule the right number of
workers for the job right away (taking into account the main thread
contributes), whereas PostJob().Join() schedules 1 worker that won't
be necessary once doing Join() and the main thread kicks in.
This has the effect of reducing 1 unnecessary context switch each time
the jobs are schedule.

Bug: chromium:1287665
Change-Id: Ie262f8904cc8ac78d9e5cbd23ef28dc5b013a625
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746080Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82047}
      a2993308
    • Marja Hölttä's avatar
      [rab/gsab] Fix error handling in GetDerivedRabGsabMap · 0d0e73e6
      Marja Hölttä authored 
      It was delegating to GetDerivedMap but not handling the possible
error coming from it.

Bug: v8:11111,chromium:1347722
Change-Id: I348ed721281d8edd324f0e364d8ed45602cb9f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791063Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Marja Hölttä <marja@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82046}
      0d0e73e6
    • Seth Brenith's avatar
      Reland "Background merging of deserialized scripts" · 766b2a4d
      Seth Brenith authored 
      This is a reland of commit e895b7af

The unit test has been updated to work correctly when
--stress-incremental-marking is enabled.

Original change's description:
> Background merging of deserialized scripts
>
> Recently, https://crrev.com/c/v8/v8/+/3681880 added new API functions
> with which an embedder could request that V8 merge newly deserialized
> script data into an existing Script from the Isolate's compilation
> cache. This change implements those new functions. This functionality is
> still disabled by default due to the flag
> merge_background_deserialized_script_with_compilation_cache.
>
> The goal of this new functionality is to reduce memory usage when
> multiple frames load the same script with a long delay between (long
> enough for the script to have been evicted from Blink's in-memory cache
> and for the top-level SharedFunctionInfo to be flushed). In that case,
> there are two Script objects for the same script: one which was found in
> the Isolate compilation cache (the "old" script), and one which was
> recently deserialized (the "new" script). The new script's object graph
> is essentially standalone: it may point to internalized strings and
> readonly objects such as the empty feedback metadata, but otherwise
> it is unconnected to the rest of the heap. The merging logic takes any
> useful data from the new script's object graph and attaches it into the
> old script's object graph, so that the new Script object and any other
> duplicated objects can be discarded. More specifically:
>
> 1. If the new Script has a SharedFunctionInfo for a particular function
>    literal, and the old Script does not, then the old Script is updated
>    to refer to the new SharedFunctionInfo.
> 2. If the new Script has a compiled SharedFunctionInfo for a particular
>    function literal, and the old Script has an uncompiled
>    SharedFunctionInfo, then the old SharedFunctionInfo is updated to
>    point to the function_data and feedback_metadata from the new
>    SharedFunctionInfo.
> 3. If any used object from the new object graph points to a
>    SharedFunctionInfo, where the old object graph contains a matching
>    SharedFunctionInfo for the same function literal, then that pointer
>    is updated to point to the old SharedFunctionInfo.
>
> The document at [0] includes diagrams showing an example merge on a very
> small script.
>
> Steps 1 and 2 above are pretty simple, but step 3 requires walking a
> possibly large set of objects, so this new API lets the embedder run
> step 3 from a background thread. Steps 1 and 2 are performed later, on
> the main thread.
>
> The next important question is: in what ways can the old script's object
> graph be modified during the background execution of step 3, or during
> the time after step 3 but before steps 1 and 2?
>
> A. SharedFunctionInfos can go from compiled to uncompiled due to
>    flushing. This is okay; the worst outcome is that the function would
>    need to be compiled again later. Such a risk is already present,
>    since V8 doesn't keep IsCompiledScopes for every compiled function in
>    a background-deserialized script.
> B. SharedFunctionInfos can go from uncompiled to compiled due to lazy
>    compilation. This is also okay; the merge completion logic on the
>    main thread will just keep this lazily compiled data rather than
>    inserting compiled data from the newly deserialized object graph.
> C. SharedFunctionInfos can be cleared from the Script's weak array if
>    they are no longer referenced. This is mostly okay, because any
>    SharedFunctionInfo that is needed by the background merge is strongly
>    referenced and therefore can't be cleared. The only problem arises if
>    the top-level SharedFunctionInfo gets cleared, so the merge task must
>    deliberately keep a reference to that one.
> D. SharedFunctionInfos can be created if they are needed due to lazy
>    compilation of a parent function. This change is somewhat troublesome
>    because it invalidates the background thread's work and requires a
>    re-traversal on the main thread to update any pointers that should
>    point to this lazily compiled SharedFunctionInfo.
>
> At a high level, this change implements three previously unimplemented
> functions in BackgroundDeserializeTask (in compiler.cc) and updates one:
>
> - BackgroundDeserializeTask::SourceTextAvailable, run on the main
>   thread, checks whether there is a matching Script in the Isolate
>   compilation cache which doesn't already have a top-level
>   SharedFunctionInfo. If so, it saves that Script in a persistent
>   handle.
> - BackgroundDeserializeTask::ShouldMergeWithExistingScript checks
>   whether the persistent handle from the first step exists (a fast
>   operation which can be called from any thread).
> - BackgroundDeserializeTask::MergeWithExistingScript, run on a
>   background thread, performs step 3 of the merge described above and
>   generates lists of persistent data describing how the main thread can
>   complete the merge.
> - BackgroundDeserializeTask::Finish is updated to perform the merge
>   steps 1 and 2 listed above, as well as a possible re-traversal of the
>   graph if required due to newly created SharedFunctionInfos in the old
>   Script.
>
> The merge logic has nothing to do with deserialization, and indeed I
> hope to reuse it for background compilation tasks as well, so it is all
> contained within a new class BackgroundMergeTask (in compiler.h,cc). It
> uses a second class, ForwardPointersVisitor (in compiler.cc) to perform
> the object visitation that updates pointers to SharedFunctionInfos.
>
> [0] https://docs.google.com/document/d/1UksB5Vm7TT1-f3S9W1dK_rP9jKn_ly0WVm_UDPpWuBw/edit
>
> Bug: v8:12808
> Change-Id: Id405869e9d5b106ca7afd9c4b08cb5813e6852c6
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3739232
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#81941}

Bug: v8:12808
Change-Id: Id2036dfa4eba8670cac899773d7a906825fa2c50
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3787266Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#82045}
      766b2a4d
    • Leszek Swirski's avatar
      [maglev] Fix deopt condition in Int32Div · c34c85a5
      Leszek Swirski authored 
      1. A remainder equal to zero means no deopt.
2. We need the input value in the input register, so we need to treat
   rax as a clobbered temporary instead of a fixed input.

Bug: v8:7700
Change-Id: I9a7b7f3cc48e17b262aa7f9084fa864ad505be54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3788099
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82044}
      c34c85a5
    • Milad Fa's avatar
      PPC/s390: [Cleanup] Use CmpInstanceTypeRange in MacroAssembler · 04483dbb
      Milad Fa authored 
      Port ec6368bf

R=yahan@iscas.ac.cn, joransiu@ca.ibm.com, junyan@redhat.com, midawson@redhat.com
BUG=
LOG=N

Change-Id: I268121f4b3ec66ca3b545551c337066ec5d7cdc5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3791905
Commit-Queue: Milad Farazmand <mfarazma@redhat.com>
Reviewed-by: 's avatarJoran Siu <joransiu@ca.ibm.com>
Reviewed-by: 's avatarJunliang Yan <junyan@redhat.com>
Cr-Commit-Position: refs/heads/main@{#82043}
      04483dbb