Skip to content

V
V8
Switch branch/tag
  1. 17 Jun, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Use BasicMemoryChunk::FromHeapObject more · 6f267e8a
      Dan Elphick authored 
      Since ReadOnlySpace pages will soon not be MemoryChunks, change most
uses of MemoryChunk::FromHeapObject and FromAddress to use the
BasicMemoryChunk variants and which use the new MemoryChunk::cast
function that takes a BasicMemoryChunk and DCHECKs !InReadOnlySpace().

To enable this, it also moves into BasicMemoryChunk several MemoryChunk
functions that just require a BasicMemoryChunk.

Bug: v8:10454
Change-Id: I80875b2c2446937ac2c2bc9287d36e71cc050c38
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2243216
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68390}
      6f267e8a
  3. 05 May, 2020 1 commit
  5. 24 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Reland "[offthread] Move stress-background-compile to compiler.cc" · 471b2001
      Leszek Swirski authored 
      This is a reland of a441cbfb

Disabling cctest/test-compiler/DeepEagerCompilationPeakMemory in stress
mode since allocation is no longer deterministic.

Original change's description:
> [offthread] Move stress-background-compile to compiler.cc
>
> Make --stress-background-compile a V8 flag rather than a d8 flag, so
> that it also tests unittests/cctests.
>
> Now, with this flag, every top-level script compile (that fulfills a
> couple of restrictions) will be both main-thread and background-thread
> compiled, taking the result of the background compile. In the future,
> we'll probably want to verify that the two results are equivalent.
>
> One of the necessary changes to allow tests to pass was to introduce a
> concept of a "temporary" script (with a temporary script id), which
> doesn't get added to the script list. This is to avoid the main-thread
> compile part of the stress-test having a debugger-visible side-effect,
> e.g. in tests that enumerate scripts. We can't just create new ids for
> such scripts, as then script-id expectation files no longer match.
>
> Bug: chromium:1011762
> Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67332}

TBR=rmcilroy@chromium.org

Bug: chromium:1011762
Change-Id: I5f9f0eb71caa4829e72b4a6d2824cbebd3698bd5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2162876Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67356}
      471b2001
  7. 23 Apr, 2020 2 commits
    • Bill Budge's avatar
      Revert "[offthread] Move stress-background-compile to compiler.cc" · 5f040f9b
      Bill Budge authored 
      This reverts commit a441cbfb.

Reason for revert: causes DeepEagerCompilationPeakMemory to fail.

https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/36681

Original change's description:
> [offthread] Move stress-background-compile to compiler.cc
> 
> Make --stress-background-compile a V8 flag rather than a d8 flag, so
> that it also tests unittests/cctests.
> 
> Now, with this flag, every top-level script compile (that fulfills a
> couple of restrictions) will be both main-thread and background-thread
> compiled, taking the result of the background compile. In the future,
> we'll probably want to verify that the two results are equivalent.
> 
> One of the necessary changes to allow tests to pass was to introduce a
> concept of a "temporary" script (with a temporary script id), which
> doesn't get added to the script list. This is to avoid the main-thread
> compile part of the stress-test having a debugger-visible side-effect,
> e.g. in tests that enumerate scripts. We can't just create new ids for
> such scripts, as then script-id expectation files no longer match.
> 
> Bug: chromium:1011762
> Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#67332}

TBR=rmcilroy@chromium.org,leszeks@chromium.org

Change-Id: I8716b332b07fe4f394b5a32c986bbe652325582d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:1011762
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163143Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67347}
      5f040f9b
    • Leszek Swirski's avatar
      [offthread] Move stress-background-compile to compiler.cc · a441cbfb
      Leszek Swirski authored 
      Make --stress-background-compile a V8 flag rather than a d8 flag, so
that it also tests unittests/cctests.

Now, with this flag, every top-level script compile (that fulfills a
couple of restrictions) will be both main-thread and background-thread
compiled, taking the result of the background compile. In the future,
we'll probably want to verify that the two results are equivalent.

One of the necessary changes to allow tests to pass was to introduce a
concept of a "temporary" script (with a temporary script id), which
doesn't get added to the script list. This is to avoid the main-thread
compile part of the stress-test having a debugger-visible side-effect,
e.g. in tests that enumerate scripts. We can't just create new ids for
such scripts, as then script-id expectation files no longer match.

Bug: chromium:1011762
Change-Id: I500bbf2cabea762e69aca3dbae247daae71192cb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2120541
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67332}
      a441cbfb
  9. 20 Mar, 2020 1 commit
  11. 09 Mar, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] Generate GC object visitors for Torque classes · 4f4d73f2
      Tobias Tebbi authored 
      In the process:

* Augment C++-generated Torque classes with SizeFor methods to
  calculate size of instances.

* Add a new "@generateBodyDescriptor" annotation that causes Torque to
  generate C++ BodyDescriptors code that can be used to visit objects
  compatible with existing V8 mechanisms, e.g. GC

* Fully automate C++ macro machinery so that adding non-extern Torque
  class doesn't require any C++ changes, including ensuring generation
  of instance types and proper boilerplate for validators and
  printers.

* Make handling of @export a true annotation, allowing the modifier to
  be used on class declarations.

* Add functionality such that classes with the @export annotation are
  available to be used from C++. Field accessors for exported classes
  are public and factory methods are generated to create instances of
  the objects from C++.

* Change the Torque compiler such that Non-exported classes implicitly
  have the @generateBodyDescriptor annotation added and causes both
  verifiers and printers to be generated.

* Switch non-extern Torque classes from using existing Struct-based
  machinery to being first-class classes that support more existing
  Torque class features.

Change-Id: Ic60e60c2c6bd7acd57f949bce086898ad14a3b03
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2007490
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66621}
      4f4d73f2
  13. 04 Mar, 2020 1 commit
  15. 03 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      [cleanup] Make Hashtable Shapes return Map Handles · 5aaccdcf
      Leszek Swirski authored 
      Make Hashtable Shapes return Map Handles (from the read-only roots)
instead of the root index of the Map, so that they can be used off
the main thread.

Bug: chromium:1011762
Change-Id: I4c0a8518dc1c6d490b5c04da05b5319081a6fae5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083298
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66569}
      5aaccdcf
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored 
      Add the remaining missing templatizations to allow an initial wiring in
of the off-thread factory into streaming compilation finalization.

The off-thread finalization is behind a flag, disabled by default:
    --finalize-streaming-on-background

When the flag is enabled, background tasks will perform perform the
finalization during their background execution, and will release the
parser and compilation jobs once they are no longer needed.

The implementation is complete enough for performance testing, but not
enough for launch. Notably, there is no support for:

  * Class boilerplates (the code is marked unreachable),
  * Exceptions during finalization, i.e. parse/compile warnings/errors,
  * Allocation sampling,
  * Logging,
  * Asm.js,
  * Parallel complication tasks
  * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")

This patch also adds some tracing events for the various stages of the
off-thread finalization (including the main-thread merge) for further
performance improvements.

Bug: chromium:1011762
Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
  17. 02 Mar, 2020 1 commit
  19. 20 Feb, 2020 1 commit
  21. 13 Feb, 2020 1 commit
  23. 12 Feb, 2020 2 commits
  25. 11 Feb, 2020 2 commits
  27. 10 Feb, 2020 1 commit
  29. 06 Feb, 2020 1 commit
  31. 04 Feb, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] OffThreadFactory support for BigInt · aa3aaa76
      Leszek Swirski authored 
      This CL templatizes some methods in BigInt on the Isolate type, to allow
BigInts to be allocated off-thread from a BigInt literal.

A necessary side-effect is exporting the Isolate class in its entirety,
to allow it to be used as a specializing type for ' HandleFor' in
unittests.

Bug: chromium:1011762
Change-Id: I768f9e4d46a4532d6818d9a67c13801bc5952e5d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2036079
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66105}
      aa3aaa76
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored 
      The Factory/OffThreadFactory allows us to cleanly separate object
construction behaviour between main-thread and off-thread in a
syntactically consistent way (so that methods templated on the factory
type can be made to work on both).

However, there are cases where we also have to access the Isolate, for
handle creation or exception throwing. So far we have been pushing more
and more "customization points" into the factories to allow these
factory-templated methods to dispatch on this isolate behaviour via
these factory methods. Unfortunately, this is an increasing layering
violation between Factory and Isolate, particularly around exception
handling.

Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
way as OffThreadFactory is analogous to Factory. All methods which were
templated on Factory are now templated on Isolate, and methods which
used to take an Isolate, and which were recently changed to take a
templated Factory, are changed/reverted to take a templated Isolate.
OffThreadFactory gets an isolate() method to match Factory's.

Notably, FactoryHandle is changed to "HandleFor", where the template
argument can be either of the Isolate type or the Factory type (allowing
us to dispatch on both depending on what is available).

Bug: chromium:1011762
Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  33. 17 Jan, 2020 1 commit
  35. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored 
      Add support for internalizing an AstValueFactory using the off-thread
factory. Includes adding ConsString support to OffThreadFactory.

This introduces a Handle union wrapper, which is used in locations that
can store a Handle or an OffThreadHandle. This is used in this patch for
the internalized "string" field of AST strings, and will be able to be
used for other similar fields in other classes (e.g. the ScopeInfo
handle in Scope, object boilerplate descriptor handles, the inferred
name handle on FunctionLiterals, etc.). It has a Factory-templated
getter which returns the appropriate handle for the factory, and a
debug-only tag to make sure the right getter is used at runtime. This
union wrapper currently decomposes implicitly to a Handle if the getter
is not called, to minimise code changes, but this implicit conversion
will likely be removed for clarity.

Bug: chromium:1011762
Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  37. 15 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory · e659917a
      Leszek Swirski authored 
      Introduce OffThreadFactory with initial string construction support.

The OffThreadFactory shares with Factory a new CRTP base class, called
FactoryBase. Methods in FactoryBase return a FactoryHandle<Factory, T>
alias, which is Handle<T> for normal Factory and a new OffThreadHandle<T>
for OffThreadFactory. OffThreadHandle<T> behaves like Handle<T>, except
it stores the object in-line rather than needing external storage.

Any shared factory methods are moved into FactoryBase, which uses CRTP
to call the sub-class's AllocateRaw method (plus a few more customization
points which need Isolate access on the main thread).

Methods that used to take an Isolate or Factory, and are needed off the
main thread, are now expected to be templated on the factory type and
to use the appropriate handle.

Once an OffThreadFactory has finished being used (e.g. off-thread
compilation completed) its pages are "Published" into the main-thread
Heap. To deal with string internalization without creating a bunch of
ThinStrings, this is done in two stages:

  1. 'FinishOffThread': The off-thread pages are walked to
     collect all slots pointing to "internalized" strings. After this is
     called it is invalid to allocate any more objects with the factory.
  2. 'Publish': On the main thread, we transform these slots into
     <Handle to holder, offset> pairs, then for each saved slot
     re-internalize its string and update the slot to point to the
     internalized string.

Bug: chromium:1011762
Change-Id: I008a694da3c357de34362bd86fe7e1f46b535d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1992434
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65787}
      e659917a