Skip to content

V
V8
Switch branch/tag
  1. 05 Aug, 2021 1 commit
  3. 04 Aug, 2021 1 commit
  5. 03 Aug, 2021 1 commit
  7. 29 Jul, 2021 1 commit
  9. 26 Jul, 2021 1 commit
  11. 22 Jul, 2021 1 commit
  13. 20 Jul, 2021 3 commits
  15. 19 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Make JSFunction bg-serialized · 0dba97f8
      Jakob Gruber authored 
      This wraps up the transition away from kSerialized ref kinds.

Since JSFunctionRef is a complex type, we don't attempt full
consistency on the background thread. Instead, we serialize functions
on the background in a partially-racy manner, in which consistency
between different JSFunction fields is *not* guaranteed. Consistency
is later verified through a new compilation dependency kind during
finalization.

Bug: v8:7790, v8:12004
Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75789}
      0dba97f8
  17. 08 Jul, 2021 1 commit
  19. 01 Jul, 2021 1 commit
  21. 30 Jun, 2021 2 commits
  23. 18 Jun, 2021 1 commit
  25. 16 Jun, 2021 1 commit
  27. 10 Jun, 2021 1 commit
  29. 07 Jun, 2021 2 commits
  31. 25 May, 2021 1 commit
  33. 18 May, 2021 1 commit
  35. 17 May, 2021 1 commit
  37. 06 May, 2021 2 commits
    • Fanchen Kong's avatar
      Collect receiver to feedback for prototype.apply · 519c82ce
      Fanchen Kong authored 
      When a function is invoked by prototype.apply, it may undergo following transformation in the JSCallReducer:
	receiver.apply(this, args) ->
	this.receiver(...args) Since the new target (also the receiver of apply()) is not collected to the feedback slot, further speculative optimization on the new target is not available if the new target
is not a heapconstant.

With this CL, the receiver will be collected to the feedback instead of the target if the target is a prototype.apply. It may improve the performance of the following usecase by ~80%.

function reduceArray(func, arr, r) {
    for (var i = 0, len = arr.length; i < len; i++) {
            r = func.apply(null, r, arr[i]);
    }
    return r;
}

var a = 0; for (var i = 0; i < 10000000; i++) {
    a += reduceArray(Math.imul, [5,6,2,3,7,6,8,3,7,9,2,5,], 1);
}
console.log(a);

This CL also improves the runTime score of JetStream2/richards-wasm by ~45% in default, ~60% with --turbo-inline-js-wasm-calls.

Change-Id: I542eb8d3fcb592f4e0993af93ba1af70e89c3982
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639813
Commit-Queue: Fanchen Kong <fanchen.kong@intel.com>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74413}
      519c82ce
    • Georg Neis's avatar
      [compiler] Get rid of ShouldHaveBeenSerialized() · 13a89b00
      Georg Neis authored 
      This is a simplification and cleanup.

Bug: v8:7790
Change-Id: I93a3ed2c9ddce4e300f25032be2085aef915ed8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2874655
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74396}
      13a89b00
  39. 05 May, 2021 3 commits
  41. 22 Apr, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Support GetPropertyAccessInfo in a concurrent setting · 1277bb5c
      Jakob Gruber authored 
      Until this CL, the JSHeapBroker::GetPropertyAccessInfo (GPAI) process
was as follows:

 1. GPAI is called on the main thread (MT) during the serialization
    phase to create and cache PAIs.
 2. GPAI is called again from the background thread (BT); only cached
    PAIs from step 1 are usable.

As part of concurrent inlining, the goal is to move GPAI fully to the
background thread. This CL takes a major step in that direction by
making GPAI itself callable from the BT without resorting solely to PAIs
that were previously cached on the MT.

There are two main reasons why GPAI previously had to run on the MT:

 a) Concurrent access to Maps and other heap objects.
 b) Serialization and creation of ObjectRefs for objects discovered
    during GPAI.

This CL addresses only reason a) and leaves b) for future work. This
is done by keeping the two-pass approach, s.t. the initial call of
GPAI on the MT discovers and serializes objects. We then clear all
cached PAIs. The second call of GPAI on the BT thus runs full logic in a
concurrent setting.

Once all relevant objects (= maps and prototypes) no longer require
MT-serialization, reason b) is also addressed and the first pass can be
removed.

The new logic is implemented behind the runtime flag
--turbo-concurrent-get-property-access-info (default true), intended
to be removed in the future.

Bug: v8:7790
Change-Id: Idbdbfe091d7316529246a686bb6d71c2a0f06f8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2817793
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74120}
      1277bb5c
  43. 21 Apr, 2021 1 commit
  45. 13 Apr, 2021 1 commit
    • Maya Lekova's avatar
      [turbofan] Move large array allocation bailout earlier · 930f2654
      Maya Lekova authored 
      The CanAllocateArray used to be executed during JSCreateLowering,
leading to bailouts when large arrays are passed as arguments to
an async function or a bound function. This meant that
JSCreateAsyncFunctionObject or JSCreateBoundFunction will reach
JSGenericLowering, where they are not lowered. This CL moves
the checks earlier in the pipeline during JSNativeContextSpecialization
and JSCallReducer respectively, so that those operators are not
created at all in such cases and we bail out to the runtime instead.

Bug: v8:11564
Change-Id: I232ce7d9378730ae0cc8690e52fde840a484e069
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807609
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73928}
      930f2654
  47. 12 Apr, 2021 1 commit
    • Wenyu Zhao's avatar
      Allowing map word to be used for other state in GC header. · 5e0b94c4
      Wenyu Zhao authored 
      This CL adds features to pack/unpack map words.

Currently V8 cannot store extra metadata in object headers -- because V8
objects do not have a proper header, but only a map pointer at the start
of the object. To store per-object metadata like marking data, a side
table is required as the per-object metadata storage.

This CL enables V8 to use higher unused bits in a 64-bit map word as
per-object metadata storage. Map pointer stores come with an extra step
to encode the metadata into the pointer (we call it "map packing").
Map pointer loads will also remove the metadata bits as well (we call it
"map packing").

Since the map word is no longer a valid pointer after packing, we also
change the tag of the packed map word to make it looks like a Smi. This
helps various GC and barrier code to correctly skip them instead of
blindly dereferencing this invalid pointer.

A ninja flag `v8_enable_map_packing` is provided to turn this
map-packing feature on and off. It is disabled by default.

* Only works on x64 platform, with `v8_enable_pointer_compression`
  set to `false`

Bug: v8:11624
Change-Id: Ia2bdf79553945e5fc0b0874c87803d2cc733e073
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247561Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73915}
      5e0b94c4
  49. 23 Mar, 2021 4 commits
  51. 03 Mar, 2021 1 commit
    • Frank Emrich's avatar
      [dict-proto] TF support for constants in dictionary mode protos, pt. 1 · a3ad3529
      Frank Emrich authored 
      This CL is the first in a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.

This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.

This particular CL does the following:

a) In PropertyAccessInfo::Kind, rename kDataConstant and
kAccessorConstant to kFastDataConstant and kFastAccessorConstant,
respectively, to indicate that these kinds are used for fast mode
holders.

b) In PropertyAccessInfo::Kind, add kDictionaryProtoDataConstant and
kDictionaryProtoAccessorConstant, which will be used for dictionary
mode holders (which must also be prototypes, as stated  above).

c) Add a member dictionary_index_ to PropertyAccessInfo, which is
used by the kinds mentioned in b)

Bug: v8:11248
Change-Id: Id1c10215aab287066a9765756f112c8035141013
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718228
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73169}
      a3ad3529
  53. 24 Feb, 2021 2 commits
  55. 23 Feb, 2021 1 commit
  57. 22 Feb, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Split up GetOwnConstantElement · bd7da651
      Jakob Gruber authored 
      This method used to be defined on Object and handled Strings and
JSObjects; but only the object hierarchy rooted at JSObject has
'elements', and Strings are handled slightly differently. Thus it
makes sense to split up into

 JSObject::GetOwnConstantElement
 String::GetCharAsString

This way, we can also separate future work on making JSObjects and
Strings never-serialized.

Bug: v8:7790
Change-Id: I8e0f142fbd9cbf8e8abe1e9a189bcd948c2f1fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704080
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72911}
      bd7da651