Skip to content

V
V8
Switch branch/tag
  1. 20 Aug, 2019 1 commit
  3. 30 Jul, 2019 1 commit
    • Sathya Gunasekaran's avatar
      [WeakRefs] Make cleanup callback run as a task · 743ce772
      Sathya Gunasekaran authored 
      Previously, this was run as a microtask and this CL changes it to run
as a separate task as mandated by the current WeakRef spec.

This CL also introduces a FinalizationGroup type to the V8 API
representing the JSFinalizationGroup. This has a `Cleanup`
function that runs the cleanup callback associated with it.

SetHostCleanupFinalizationGroupCallback is added to set
the embedder defined HostCleanupFinalizationGroupCallback.

ClearKeptObject is exposed on the v8::Isolate to reset the strongly
held set of objects.

The general workflow is the following:

(a) When the GC notices that a given finalization group has dirty
    cells, it calls HostCleanupFinalizationGroupCallback with the given
    finalization group.

(b) As part of HostCleanupFinalizationGroupCallback, the embedder
    enqueues a task that at some point later calls
    FinalizationGroup::Cleanup.

(c) At some point in the future, FinalizationGroup::Cleanup is called,
    which runs the cleanup callback of the finalization group.

This patch also includes d8 changes to use these new APIs. Currently,
d8 cycles through the enqueued finalization groups after a synchronous
turn (and it's microtask checkpoint) and runs the cleanup callbacks.

Change-Id: I06eb4da2c103b2792a9c62bc4b98fd4e5c4892fc
Bug: v8:8179
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1655655
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62984}
      743ce772
  5. 02 Jul, 2019 1 commit
    • Andreas Haas's avatar
      [wasm] Introduce WasmIndirectFunctionTable · 2fe2a08b
      Andreas Haas authored 
      This is the first of three CLs which refactors indirect function calls
through tables with index > 0 to work without runtime calls.

The first CL introduces the WasmIndirectFunctionTable heap object. For
a table of type anyfunc within a WebAssembly instance,
WasmIndirectFunctionTable stores the size, the signature id's, the
call targets, and the reference parameters for that table. I used the
names that are already used for the matching fields of the
WasmInstanceObject.

The second CL expands the IndirectFunctionTableEntry to work also on
WasmIndirectFunctionTable objects. All changes to a function table go
through this class.

The third CL introduces uses of the WasmIndirectFunctionTable. In this
CL I change the code generation in TurboFan to replace runime calls with
direct accesses to the new WasmIndirectFunctionTable. Additionally I
extended the initialization of WasmIndirectFunctionTable, and also
implement Table.grow.

R=jkummerow@chromium.org

Bug: v8:7581
Change-Id: I0ecfcb9565e992ddba087d46c1f0e952abfa5822
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1681134Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62492}
      2fe2a08b
  7. 27 Jun, 2019 1 commit
  9. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      Mathias Bynens authored 
      We currently use the class name “JSValue” for JSObjects that wrap
primitive values. This name is a common source of confusion. This patch
switches to a name that’s more clear.

In addition to manual tweaks, the patch applies the following mechanical
global replacements:

before                          | after
--------------------------------|--------------------------------------
if_valueisnotvalue              | if_valueisnotwrapper
if_valueisvalue                 | if_valueiswrapper
js_value                        | js_primitive_wrapper
JS_VALUE_TYPE                   | JS_PRIMITIVE_WRAPPER_TYPE
JSPrimitiveWrapperType          | JSPrimitiveWrapper type
jsvalue                         | js_primitive_wrapper
JSValue                         | JSPrimitiveWrapper
_GENERATED_JSVALUE_FIELDS       | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS

Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  11. 21 Jun, 2019 1 commit
    • Sigurd Schneider's avatar
      [torque] Support 'real' internal classes · 76c1e829
      Sigurd Schneider authored 
      Rework the implementation of non-external Torque classes to use
Struct machinery rather than FixedArray machinery. This allows
Torque-only defined 'internal' classes to the automatically generate
class verifiers and printers.

As part of this change, generate C++ boilerplate accessors for
internal Torque classes, since this is a pre-requisite for the
verifiers, printers and other Struct-based functionality.

Moreover, augment the header-generating functionality in Torque
to create separate header files for field offset definitions,
internal class C++ definitions and instance types.

Bug: v8:7793
Change-Id: I47d5f1570040c2b44d378f23b6cf95d3d132dacc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1607645
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62317}
      76c1e829
  13. 19 Jun, 2019 1 commit
  15. 27 May, 2019 3 commits
    • Benedikt Meurer's avatar
      Reland "[typedarray] Move external/data pointer to JSTypedArray." · 70bd7cf0
      Benedikt Meurer authored 
      This is a reland of 4b86fea5 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}
      70bd7cf0
    • Clemens Hammacher's avatar
      Revert "[typedarray] Move external/data pointer to JSTypedArray." · e4db146a
      Clemens Hammacher authored 
      This reverts commit 4b86fea5.

Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045

Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
> 
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
> 
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
> 
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
> 
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}

TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org

Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61856}
      e4db146a
    • Benedikt Meurer's avatar
      [typedarray] Move external/data pointer to JSTypedArray. · 4b86fea5
      Benedikt Meurer authored 
      As the next step in supporting huge typed arrays in V8, this moves the
external/data pointer from the FixedTypedArrayBase backing store to the
JSTypedArray instance itself, and replaces the special backing stores
with a plain ByteArray (removing all the code for the FixedTypedArrayBase
class hierarchy). By doing so, we can drastically simplify the system
around typed arrays.

Note: Several places in the code base used to check the instance type
of the elements backing store of a JSTypedArray instead of checking the
elements kind on the JSTypedArray map directly. Those had to be fixed,
since the backing store is now always a ByteArray.

Drive-by-fix: Move all the typed elements access related code into the
elements.cc file to properly encapsulate the accesses.

Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61855}
      4b86fea5
  17. 23 May, 2019 4 commits
  19. 20 May, 2019 1 commit
  21. 08 May, 2019 1 commit
  23. 25 Apr, 2019 1 commit
  25. 18 Apr, 2019 1 commit
  27. 17 Apr, 2019 1 commit
  29. 25 Mar, 2019 1 commit
    • Mythri's avatar
      [lite] Allocate feedback vectors lazily · 7629afdb
      Mythri authored 
      Allocate feedback vectors lazily when the function's interrupt budget has
reached a specified threshold. This cl introduces a new field in the
ClosureFeedbackCellArray to track the interrupt budget for allocating
feedback vectors. Using the interrupt budget on the bytecode array could
cause problems when there are closures across native contexts and we may
delay allocating feedback vectors in one of them causing unexpected
performance cliffs. In the long term we may want to remove interrupt budget
from bytecode array and use context specific budget for tiering up decisions
as well.

Bug: v8:8394
Change-Id: Ia8fbb71f5e8543a92f14c44aa762973da82d445c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1520719
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60450}
      7629afdb
  31. 19 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [turbofan] Significantly improve ConsString creation performance. · d6a60a0e
      Benedikt Meurer authored 
      This change significantly improves the performance of string
concatenation in optimized code for the case where the resulting string
is represented as a ConsString. On the relevant test cases we go from

  serializeNaive: 10762 ms.
  serializeClever: 7813 ms.
  serializeConcat: 10271 ms.

to

  serializeNaive: 10278 ms.
  serializeClever: 5533 ms.
  serializeConcat: 10310 ms.

which represents a 30% improvement on the "clever" benchmark, which
tests specifically the ConsString creation performance.

This was accomplished via a couple of different steps, which are briefly
outlined here:

  1. The empty_string gets its own map, so that we can easily recognize
     and handle it appropriately in the TurboFan type system. This
     allows us to express (and assert) that the inputs to NewConsString
     are non-empty strings, making sure that TurboFan no longer creates
     "crippled ConsStrings" with empty left or right hand sides.
  2. Further split the existing String types in TurboFan to be able to
     distinguish between OneByte and TwoByte strings on the type system
     level. This allows us to avoid having to dynamically lookup the
     resulting ConsString map in case of ConsString creation (i.e. when
     we know that both input strings are OneByte strings or at least
     one of the input strings is TwoByte).
  3. We also introduced more finegrained feedback for the Add bytecode
     in the interpreter, having it collect feedback about ConsStrings,
     specifically ConsOneByteString and ConsTwoByteString. This feedback
     can be used by TurboFan to only inline the relevant code for what
     was seen so far. This allows us to remove the Octane/Splay specific
     magic in JSTypedLowering to detect ConsString creation, and instead
     purely rely on the feedback of what was seen so far (also making it
     possible to change the semantics of NewConsString to be a low-level
     operator, which is only introduced in SimplifiedLowering by looking
     at the input types of StringConcat).
  4. On top of the before mentioned type and interpreter changes we added
     new operators CheckNonEmptyString, CheckNonEmptyOneByteString, and
     CheckNonEmptyTwoByteString, which perform the appropriate (dynamic)
     checks.

There are several more improvements that are possible based on this, but
since the change was already quite big, we decided not to put everything
into the first change, but do some follow up tweaks to the type system,
and builtin optimizations later.

Tbr: mstarzinger@chromium.org
Bug: v8:8834, v8:8931, v8:8939, v8:8951
Change-Id: Ia24e17c6048bf2b04df966d3cd441f0edda05c93
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1499497
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJaroslav Sevcik <jarin@chromium.org>
Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60318}
      d6a60a0e
  33. 04 Mar, 2019 1 commit
    • Benedikt Meurer's avatar
      [cleanup] Remove obsolete "one byte data hint" for strings. · 683cf6f4
      Benedikt Meurer authored 
      In the early days of Chrome when we used WebKit there was no support for
ASCII strings on the C++ side, so we put a hint onto these two-byte
strings that said "string only contains one byte data", such that
internally in V8 when these were involved in string operations, we could
instead create the *cheaper* one byte strings.

Nowadays Blink properly supports one-byte string representations and
this additional hint only comes with overhead, since we check it in
quite a few places (i.e. on the hot path for string concatenation), plus
we end up consuming more memory due to the additional string maps.
Removing the hint also frees one bit in the InstanceType zoo for
strings.

This alone improves performance on the `bench-dom-serialize.js` test case
by around **3%**.

Tbr: mstarzinger@chromium.org
Bug: v8:6622, v8:8834, v8:8939
Cq-Include-Trybots: luci.chromium.try:linux-blink-rel
Change-Id: I0753f2859cee7b5a37b6f0da64d8ec39fcb044ff
Doc: https://bit.ly/fast-string-concatenation-in-javascript
Reviewed-on: https://chromium-review.googlesource.com/c/1498478
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60006}
      683cf6f4
  35. 13 Feb, 2019 1 commit
  37. 06 Feb, 2019 1 commit
  39. 01 Feb, 2019 2 commits
    • Michael Starzinger's avatar
      Revert "[serializer] share class positions tuple across contexts" · b1eb340d
      Michael Starzinger authored 
      This reverts commit a1b431d7.

Reason for revert: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/22809

Original change's description:
> [serializer] share class positions tuple across contexts
> 
> Class positions is a struct that stores the start and end positions of a class
> literal. It is stored both on class objects, and the template used to
> instantiate class objects.
> 
> The template is reachable from the bytecode array and therefore serialized by
> the startup serializer. Class objects are context-dependent and therefore
> serialized by the partial serializer. Serializing class positions from both
> serializers violates the assumption that we don't serialize any object twice.
> 
> R=​gsathya@chromium.org
> 
> Bug: v8:8761
> Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
> Reviewed-on: https://chromium-review.googlesource.com/c/1444956
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#59292}

TBR=yangguo@chromium.org,mstarzinger@chromium.org,gsathya@chromium.org

Change-Id: I9f3fd1b29b5991b450223f8b27dfc7aa7e5a3171
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8761
Reviewed-on: https://chromium-review.googlesource.com/c/1450116Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59300}
      b1eb340d
    • Yang Guo's avatar
      [serializer] share class positions tuple across contexts · a1b431d7
      Yang Guo authored 
      Class positions is a struct that stores the start and end positions of a class
literal. It is stored both on class objects, and the template used to
instantiate class objects.

The template is reachable from the bytecode array and therefore serialized by
the startup serializer. Class objects are context-dependent and therefore
serialized by the partial serializer. Serializing class positions from both
serializers violates the assumption that we don't serialize any object twice.

R=gsathya@chromium.org

Bug: v8:8761
Change-Id: If22c554cc7396d63998a015454ce0c67a7d2e05c
Reviewed-on: https://chromium-review.googlesource.com/c/1444956Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarSathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#59292}
      a1b431d7
  41. 30 Jan, 2019 1 commit
  43. 11 Jan, 2019 1 commit
  45. 29 Nov, 2018 1 commit
  47. 27 Nov, 2018 1 commit
  49. 22 Nov, 2018 2 commits
  51. 21 Nov, 2018 2 commits
  53. 20 Nov, 2018 1 commit
  55. 12 Nov, 2018 2 commits
  57. 05 Nov, 2018 1 commit
  59. 29 Oct, 2018 1 commit
  61. 18 Oct, 2018 1 commit