1. 15 Dec, 2021 1 commit
    • Samuel Groß's avatar
      V8 Sandbox rebranding · 277fdd1d
      Samuel Groß authored
      This CL renames a number of things related to the V8 sandbox.
      Mainly, what used to be under V8_HEAP_SANDBOX is now under
      V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage
      is now simply the V8 Sandbox:
      
      V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX
      V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS
      V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS
      V8VirtualMemoryCage => Sandbox
      CagedPointer => SandboxedPointer
      fake cage => partially reserved sandbox
      src/security => src/sandbox
      
      This naming scheme should simplify things: the sandbox is now the large
      region of virtual address space inside which V8 mainly operates and
      which should be considered untrusted. Mechanisms like sandboxed pointers
      are then used to attempt to prevent escapes from the sandbox (i.e.
      corruption of memory outside of it). Furthermore, the new naming scheme
      avoids the confusion with the various other "cages" in V8, in
      particular, the VirtualMemoryCage class, by dropping that name entirely.
      
      Future sandbox features are developed under their own V8_SANDBOX_X flag,
      and will, once final, be merged into V8_SANDBOX. Current future features
      are sandboxed external pointers (using the external pointer table), and
      sandboxed pointers (pointers guaranteed to point into the sandbox, e.g.
      because they are encoded as offsets). This CL then also introduces a new
      build flag, v8_enable_sandbox_future, which enables all future features.
      
      Bug: v8:10391
      Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96
      Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Samuel Groß <saelo@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78384}
      277fdd1d
  2. 10 Dec, 2021 2 commits
  3. 08 Dec, 2021 3 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Delete Jobs as BG work · 85877e54
      Leszek Swirski authored
      Deleting / deallocating Jobs, along with everything they own (e.g.
      PersistentHandles), can take a long time, especially if the allocator
      isn't too friendly to deallocating on a different thread than where the
      allocation happened.
      
      Instead, enqueue Jobs for deletion as part of background processing,
      with the hope that they end up being deallocated on the same thread as
      they were allocated, and at the very least taking the deallocation time
      off the main thread. The deletion queue is processed after the pending
      background jobs are all processed, and counts as a single "background
      job" as far as parallelism is concerned.
      
      Bug: chromium:1275157
      Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78307}
      85877e54
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move Job pointer to SFI · 3b9091c8
      Leszek Swirski authored
      Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of
      the sets and hashmaps, and instead:
      
        1. Turning the pending job set into a queue, and
        2. Making the SharedFunctionInfo's UncompiledData hold a pointer to
           the LazyCompilerDispatcher::Job, instead of maintaining an
           IdentityMap from one to the other.
      
      To avoid bloating all UncompiledData, this adds two new UncompiledData
      subclasses, making it four subclasses total, for with/without Preparse
      data and with/without a Job pointer. "should_parallel_compile"
      FunctionLiterals get allocated an UncompiledData with a job pointer by
      default, otherwise enqueueing a SFI without a job pointer triggers a
      reallocation of the UncompiledData to add a job pointer.
      
      Since there is no longer a set of all Jobs (aside from one for
      debug-only), we need to be careful to manually clear the Job pointer
      from the UncompiledData whenever we finish a Job (whether successfully
      or by aborting) and we have to make sure that we implicitly can reach
      all Jobs via the pending/finalizable lists, or the set of currently
      running jobs.
      
      Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78302}
      3b9091c8
    • Leszek Swirski's avatar
      [compiler] Introduce ReusableUnoptimizedCompileState · b3e1eb0c
      Leszek Swirski authored
      Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo,
      which stores a couple of pointers and most importantly the Zone and
      AstValueFactory of the parse. This allows the Zone and AstValueFactory
      to be reused across multiple parses, rather than re-initialising
      per-Parse.
      
      With this, we can amend the LazyCompileDispatcher to initialise one
      LocalIsolate, Zone and AstValueFactory per background thread loop,
      rather than one per compile task, which allows us to reduce per-task
      costs and re-use the AstValueFactory's string table and previous String
      internalizations.
      
      Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78289}
      b3e1eb0c
  4. 03 Dec, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler] Create ParseInfo on BG thread · a66c7a38
      Leszek Swirski authored
      Rather than creating a ParseInfo when creating a BackgroundCompileTask
      (and passing ownership across to the BG thread which deallocates it),
      create one when running it.
      
      This allows the ParseInfo Zone to be both allocated and deallocated on
      the same thread, which will improve its allocator friendliness.
      
      As a side-effect, we now use the on-heap PreparseData from the
      SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This
      means that we don't have to copy the PreparseData across Zones, but we
      do need to Unpark the LocalHeap when accessing preparse data.
      
      Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78228}
      a66c7a38
    • Leszek Swirski's avatar
      [compiler-dispatcher] Opportunistically finalize · b4f8578f
      Leszek Swirski authored
      Finalize other finalizable jobs in FinishNow, up to a time deadline.
      This deadline is set to 1ms for now, because that seems like short
      enough to not get in the way of user interaction but long enough to be
      worth doing here rather than doing another runtime call for the
      subsequent funtions.
      
      Change-Id: I79f0780e9318e97efee03d2d25701009ca7069d1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310801
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78227}
      b4f8578f
  5. 02 Dec, 2021 1 commit
  6. 01 Dec, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Enqueue tasks for non-eager inner funcs · 5ab1ec1e
      Leszek Swirski authored
      Add suppose for compiling non-eager, non-top-level inner functions in
      parallel, using the compiler dispatcher. This behaviour can be enabled
      with --parallel-compile-tasks-for-lazy.
      
      There are a couple of consequences:
      
        * To support this we need support for off-thread ScopeInfo
          deserialization, so this adds that too.
        * The previous --parallel-compile-tasks flag is renamed to the more
          descriptive --parallel-compile-tasks-for-eager-toplevel.
        * Both parallel-compile-tasks flags are moved onto
          UnoptimizedCompileFlags so that they can be enabled/disabled on a
          per-compile basis (e.g. enabled for streaming, disabled for
          re-parsing).
        * asm.js compilations can now happen without an active Context (in
          the compiler dispatcher's idle finalization) so we can't get a
          ContextId for metric reporting; we'd need to somehow fix this if we
          wanted asm.js UKM but for now it's probably fine.
        * Took the opportunity to clean up some of the "can preparse" logic in
          the parser.
      
      Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78183}
      5ab1ec1e
  7. 15 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler] Post compile tasks from ignition instead of the parser · 6b2fa4c1
      Leszek Swirski authored
      Posting compile tasks from the parser has several issues:
      
        1. We don't know how many functions there will be total, so we can't
           yet allocate shared_function_infos array on the Script
        2. Without this array, inner function compiles can't look up their own
           inner functions during bytecode finalization, so we can't run that
           finalization before script parse completes
        3. Scope analysis can't have run yet, so we can only post top-level
           function tasks and if we allocate SharedFunctionInfos early they
           are forced into a bit of a limbo state without an outer ScopeInfo.
      
      Instead, we can post compile tasks during bytecode generation. Then, the
      script parse is guaranteed to have completed, so we'll have a
      shared_function_infos array and we will have allocated ScopeInfos
      already. This also opens the door for posting tasks for compiling more
      inner functions than just top-level, as well as generating better code
      for functions/methods that reference same-script top-level
      let/const/class.
      
      Bug: chromium:1267680
      Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77894}
      6b2fa4c1
  8. 12 Nov, 2021 1 commit
  9. 05 Nov, 2021 1 commit
  10. 04 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      [compiler-dispatcher] Move to full SFI keying · 14097e62
      Leszek Swirski authored
      Remove the concept of JobId from LazyCompileDispatcher, and make SFIs
      the canonical id for these jobs.
      
      This has several consequences:
      
        * We no longer split enqueing a job and registering a SFI with that
          job. We did this previously because we could not allocate SFIs in
          the Parser -- now with LocalHeap we can, so we do.
        * We remove the separate Job vector, and make the SFI IdentityMap
          hold pointers to Jobs directly. This requires a small amount of
          extra care to deallocate Jobs when removing them from the map,
          but it means not having to allocate new global handles for jobs.
        * The SFI is passed into the BackgroundCompileTask instead of the
          script, so our task finalization doesn't need the SFI anymore.
        * We no longer need to iterate ParallelTasks after compiling (to
          register SFIs), so we can get rid of ParallelTasks entirely and
          access the dispatcher directly from the parser.
      
      There are a few drive-bys since we're touching this code:
      
        * Jobs are move to have a "state" variable rather than a collection
          of bools, for stricter DCHECKing.
        * There's no longer a set of "currently running" jobs, since this
          was only used to check if a job is running, we can instead inspect
          the job's state directly.
        * s/LazyCompilerDispatcher/LazyCompileDispatcher/g
      
      Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77712}
      14097e62
  11. 03 Nov, 2021 1 commit
    • Leszek Swirski's avatar
      Reland "[off-thread] Allow off-thread top-level IIFE finalization" · 548c40ed
      Leszek Swirski authored
      This is a reland of 35a6eeec
      
      Reland fixes:
        * Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI
          from the placeholder. This now includes copying scope_info (which
          wasn't included in the original CL and caused some of the issues)
        * Make sure that LocalHandleScope is initialised only inside of
          UnparkedScope (fixed TSAN issues)
        * Clean-up: Don't add `script_` to ParseInfo, but instead pass it
          separately to Parser. Eventually we'd ideally get rid of ParseInfo
          entirely (splitting it into input and output) so let's not add more
          fields to it. Reverts changing CreateScript to InitializeScript.
      
      Original change's description:
      > [off-thread] Allow off-thread top-level IIFE finalization
      >
      > Allow off-thread finalization for parallel compile tasks (i.e. for top-
      > level IIFEs).
      >
      > This allows us to merge the code paths in BackgroundCompileTask, and
      > re-enable the compiler dispatcher tests under the off-thread
      > finalization flag. Indeed, we can simplify further and get rid of that
      > flag entirely (it has been on-by-default for several releases now).
      >
      > Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#77615}
      
      Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77676}
      548c40ed
  12. 01 Nov, 2021 1 commit
  13. 29 Oct, 2021 2 commits
    • Leszek Swirski's avatar
      [compiler-dispatcher] Port to Jobs API · 15b1ce39
      Leszek Swirski authored
      Port the CompilerDispatcher to use the Jobs API, instead of its own
      hand-rolled worker management.
      
      This required some re-thinking of how testing is handled, since the
      tests want to be able to
      
        a) Defer calls to PostTask/Job, to actuall post the jobs later. This
           was easy enough with PostTask, since we could simply store the task
           in a list and no-op, but PostJob has to return a JobHandle. The
           tests now have a DelayedJobHandleWrapper, which defers all method
           calls on itself, and because of all the unique_ptrs, there's also
           now a SharedJobHandleWrapper.
      
        b) Wait until tasks/jobs complete. Returning from a Task meant that
           the task had completed, but this isn't necessarily the case with
           JobTasks; e.g. a job might be asked to yield. This patch hacks
           around this by Posting and Joining a non-owning copy of the
           requested JobTask, and then re-posting it once Join returns.
      
      Change-Id: If867b4122af52758ffabcfb78a6701f0f95d896d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563664
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarVictor Gomes <victorgomes@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77618}
      15b1ce39
    • Leszek Swirski's avatar
      [off-thread] Allow off-thread top-level IIFE finalization · 35a6eeec
      Leszek Swirski authored
      Allow off-thread finalization for parallel compile tasks (i.e. for top-
      level IIFEs).
      
      This allows us to merge the code paths in BackgroundCompileTask, and
      re-enable the compiler dispatcher tests under the off-thread
      finalization flag. Indeed, we can simplify further and get rid of that
      flag entirely (it has been on-by-default for several releases now).
      
      Change-Id: I54f361997d651667fa813ec09790a6aab4d26774
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#77615}
      35a6eeec
  14. 20 Sep, 2021 1 commit
  15. 06 Aug, 2021 1 commit
  16. 09 Jun, 2021 1 commit
  17. 12 Apr, 2021 1 commit
  18. 07 Oct, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^4 "[serializer] Allocate during deserialization" · 3c508b38
      Leszek Swirski authored
      This relands commit 3f4e9bbe.
      which was a reland of c4a062a9
      which was a reland of 28a30c57
      which was a reland of 5d7a29c9
      
      The change had an issue that embedders implementing heap tracing (e.g.
      Unified Heap with Blink) could be passed an uninitialized pointer if
      marking happened during deserialization of an object containing such a
      pointer. Because of the 0xdeadbed0 uninitialized filler value, these
      embedders would then receive the value 0xdeadbed0deadbed0 as the
      'pointer', and crash on dereference.
      
      There is, however, special handling already for null pointers in heap
      tracing, also for dealing with not-yet initialized values. So, we can
      make the uninitialized Smi filler be 0x00000000, and that will make such
      embedded fields have a nullptr representation, making them follow the
      normal uninitialized value bailouts.
      
      In addition, it relands the following dependent changes, which are
      relanding unchanged and are followup performance improvements.
      Relanding them in the same change should allow for cleaner reverts
      should they be needed.
      
      This relands commit 76ad3ab5
      [identity-map] Change resize heuristic
      
      This relands commit 77cc96aa
      [identity-map] Cache the calculated Hash
      
      This relands commit bee5b996
      [serializer] Remove Deserializer::Initialize
      
      This relands commit c8f73f22
      [serializer] Cache instance type in PostProcessNewObject
      
      This relands commit 4e7c99ab
      [identity-map] Remove double-lookups in IdentityMap
      
      Original change's description:
      > Reland^3 "[serializer] Allocate during deserialization"
      >
      > This is a reland of c4a062a9
      > which was a reland of 28a30c57
      > which was a reland of 5d7a29c9
      >
      > Fixes TSAN errors from non-atomic writes in the deserializer. Now all
      > writes are (relaxed) atomic.
      >
      > Original change's description:
      > > Reland^2 "[serializer] Allocate during deserialization"
      > >
      > > This is a reland of 28a30c57
      > > which was a reland of 5d7a29c9
      > >
      > > The crashes were from calling RegisterDeserializerFinished on a null
      > > Isolate pointer, for a deserializer that was never initialised
      > > (specifically, ReadOnlyDeserializer when ROHeap is shared).
      > >
      > > Original change's description:
      > > > Reland "[serializer] Allocate during deserialization"
      > > >
      > > > This is a reland of 5d7a29c9
      > > >
      > > > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > > > to not check the new space addresses until it's known that this is a new
      > > > space allocation. This fixes an UBSan failure during read-only space
      > > > deserialization, which happens before the new space is initialized.
      > > >
      > > > It also fixes some issues discovered by --stress-snapshot, around
      > > > serializing ThinStrings (which are now elided as part of serialization),
      > > > handle counts (I bumped the maximum handle count in that check), and
      > > > clearing map transitions (the map backpointer field needed a Smi
      > > > uninitialized value check).
      > > >
      > > > Original change's description:
      > > > > [serializer] Allocate during deserialization
      > > > >
      > > > > This patch removes the concept of reservations and a specialized
      > > > > deserializer allocator, and instead makes the deserializer allocate
      > > > > directly with the Heap's Allocate method.
      > > > >
      > > > > The major consequence of this is that the GC can now run during
      > > > > deserialization, which means that:
      > > > >
      > > > >   a) Deserialized objects are visible to the GC, and
      > > > >   b) Objects that the deserializer/deserialized objects point to can
      > > > >      move.
      > > > >
      > > > > Point a) is mostly not a problem due to previous work in making
      > > > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > > > size before any subsequent allocation/safepoint. We now additionally
      > > > > have to initialize the allocated space with a valid tagged value -- this
      > > > > is a magic Smi value to keep "uninitialized" checks simple.
      > > > >
      > > > > Point b) is solved by Handlifying the deserializer. This involves
      > > > > changing any vectors of objects into vectors of Handles, and any object
      > > > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > > > the object's address is no longer a stable hash).
      > > > >
      > > > > Back-references can no longer be direct chunk offsets, so instead the
      > > > > deserializer stores a Handle to each deserialized object, and the
      > > > > backreference is an index into this handle array. This encoding could
      > > > > be optimized in the future with e.g. a second pass over the serialized
      > > > > array which emits a different bytecode for objects that are and aren't
      > > > > back-referenced.
      > > > >
      > > > > Additionally, the slot-walk over objects to initialize them can no
      > > > > longer use absolute slot offsets, as again an object may move and its
      > > > > slot address would become invalid. Now, slots are walked as relative
      > > > > offsets to a Handle to the object, or as absolute slots for the case of
      > > > > root pointers. A concept of "slot accessor" is introduced to share the
      > > > > code between these two modes, and writing the slot (including write
      > > > > barriers) is abstracted into this accessor.
      > > > >
      > > > > Finally, the Code body walk is modified to deserialize all objects
      > > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > > > during a RelocInfo walk.
      > > > >
      > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > > > size rather than byte size -- the size is expected to be tagged-aligned
      > > > > anyway, so now we get an extra few bits in the size encoding.
      > > > >
      > > > > Bug: chromium:1075999
      > > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > > Cr-Commit-Position: refs/heads/master@{#70229}
      
      Bug: chromium:1075999
      Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70366}
      3c508b38
  19. 05 Oct, 2020 2 commits
    • Adam Klein's avatar
      Revert "Reland^3 "[serializer] Allocate during deserialization"" · a10ec2be
      Adam Klein authored
      This reverts commit 3f4e9bbe, along
      with the following dependent changes (reverted to make this a clean revert):
      76ad3ab5 [identity-map] Change resize heuristic
      77cc96aa [identity-map] Cache the calculated Hash
      bee5b996 [serializer] Remove Deserializer::Initialize
      c8f73f22 [serializer] Cache instance type in PostProcessNewObject
      4e7c99ab [identity-map] Remove double-lookups in IdentityMap
      
      Reason for revert: major crash spike on Canary (https://crbug.com/1135027)
      
      Original change's description:
      > Reland^3 "[serializer] Allocate during deserialization"
      >
      > This is a reland of c4a062a9
      > which was a reland of 28a30c57
      > which was a reland of 5d7a29c9
      >
      > Fixes TSAN errors from non-atomic writes in the deserializer. Now all
      > writes are (relaxed) atomic.
      >
      > Original change's description:
      > > Reland^2 "[serializer] Allocate during deserialization"
      > >
      > > This is a reland of 28a30c57
      > > which was a reland of 5d7a29c9
      > >
      > > The crashes were from calling RegisterDeserializerFinished on a null
      > > Isolate pointer, for a deserializer that was never initialised
      > > (specifically, ReadOnlyDeserializer when ROHeap is shared).
      > >
      > > Original change's description:
      > > > Reland "[serializer] Allocate during deserialization"
      > > >
      > > > This is a reland of 5d7a29c9
      > > >
      > > > This reland shuffles around the order of checks in Heap::AllocateRawWith
      > > > to not check the new space addresses until it's known that this is a new
      > > > space allocation. This fixes an UBSan failure during read-only space
      > > > deserialization, which happens before the new space is initialized.
      > > >
      > > > It also fixes some issues discovered by --stress-snapshot, around
      > > > serializing ThinStrings (which are now elided as part of serialization),
      > > > handle counts (I bumped the maximum handle count in that check), and
      > > > clearing map transitions (the map backpointer field needed a Smi
      > > > uninitialized value check).
      > > >
      > > > Original change's description:
      > > > > [serializer] Allocate during deserialization
      > > > >
      > > > > This patch removes the concept of reservations and a specialized
      > > > > deserializer allocator, and instead makes the deserializer allocate
      > > > > directly with the Heap's Allocate method.
      > > > >
      > > > > The major consequence of this is that the GC can now run during
      > > > > deserialization, which means that:
      > > > >
      > > > >   a) Deserialized objects are visible to the GC, and
      > > > >   b) Objects that the deserializer/deserialized objects point to can
      > > > >      move.
      > > > >
      > > > > Point a) is mostly not a problem due to previous work in making
      > > > > deserialized objects "GC valid", i.e. making sure that they have a valid
      > > > > size before any subsequent allocation/safepoint. We now additionally
      > > > > have to initialize the allocated space with a valid tagged value -- this
      > > > > is a magic Smi value to keep "uninitialized" checks simple.
      > > > >
      > > > > Point b) is solved by Handlifying the deserializer. This involves
      > > > > changing any vectors of objects into vectors of Handles, and any object
      > > > > keyed map into an IdentityMap (we can't use Handles as keys because
      > > > > the object's address is no longer a stable hash).
      > > > >
      > > > > Back-references can no longer be direct chunk offsets, so instead the
      > > > > deserializer stores a Handle to each deserialized object, and the
      > > > > backreference is an index into this handle array. This encoding could
      > > > > be optimized in the future with e.g. a second pass over the serialized
      > > > > array which emits a different bytecode for objects that are and aren't
      > > > > back-referenced.
      > > > >
      > > > > Additionally, the slot-walk over objects to initialize them can no
      > > > > longer use absolute slot offsets, as again an object may move and its
      > > > > slot address would become invalid. Now, slots are walked as relative
      > > > > offsets to a Handle to the object, or as absolute slots for the case of
      > > > > root pointers. A concept of "slot accessor" is introduced to share the
      > > > > code between these two modes, and writing the slot (including write
      > > > > barriers) is abstracted into this accessor.
      > > > >
      > > > > Finally, the Code body walk is modified to deserialize all objects
      > > > > referred to by RelocInfos before doing the RelocInfo walk itself. This
      > > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate
      > > > > during a RelocInfo walk.
      > > > >
      > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged
      > > > > size rather than byte size -- the size is expected to be tagged-aligned
      > > > > anyway, so now we get an extra few bits in the size encoding.
      > > > >
      > > > > Bug: chromium:1075999
      > > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e
      > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451
      > > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > > Cr-Commit-Position: refs/heads/master@{#70229}
      > > >
      > > > Bug: chromium:1075999
      > > > Change-Id: Ibc77cc48b3440b4a28b09746cfc47e50c340ce54
      > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2440828
      > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > > > Cr-Commit-Position: refs/heads/master@{#70267}
      > >
      > > Tbr: jgruber@chromium.org,ulan@chromium.org
      > > Bug: chromium:1075999
      > > Change-Id: Iaa8dc54895866ada0e34a7c9e8fff9ae1cb13f2d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2444991
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#70279}
      >
      > Tbr: jgruber@chromium.org,ulan@chromium.org
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
      > Bug: chromium:1075999
      > Change-Id: I0b9b11644aebc4cc8b07c62a0f765b24e4d73d89
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2445872
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70288}
      
      TBR=ulan@chromium.org,jgruber@chromium.org,leszeks@chromium.org,dinfuehr@chromium.org
      
      Bug: chromium:1075999, chromium:1135027
      Change-Id: I5d0d9e49c0302d94ff7291834f5f18e7a0839eb7
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng,v8_linux64_tsan_no_cm_rel_ng,v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451030Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
      Commit-Queue: Adam Klein <adamk@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70328}
      a10ec2be
    • Leszek Swirski's avatar
      [identity-map] Remove double-lookups in IdentityMap · 4e7c99ab
      Leszek Swirski authored
      Remove the pattern of calling 'Find' followed by 'Set' for IdentityMap,
      with a single 'FindOrInsert' that explicitly returns whether an existing
      entry was found, or the entry was inserted. This replaces 'Get', which
      would return either an initialised or uninitialised entry (and callers
      would rely on default initialisation to check this).
      
      Also replace 'Set' with 'Insert', which explicitly requires that the
      element didn't exist before. This matches expectations where it was
      used (where those weren't replaced wholesale with 'FindOrInsert'), and
      makes the naming consistent with 'FindOrInsert'.
      
      Change-Id: I8fb76f4ac14fb92b88474965aafb1ace5fb79145
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2443135
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Maya Lekova <mslekova@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70300}
      4e7c99ab
  20. 23 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored
      Move the persistent compilation state and Isolate inputs (such as the
      allocator, shared AST constants, hash seed, logger, etc.) which survives
      across both parse and compile, out of ParseInfo and into a new
      UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
      for per-thread state such as stack limit and RCS.
      
      In particular, this new state survives the ParseInfo being destructed,
      which means it is available after off-thread finalization. This allows a
      followup to access the PendingCompilationErrorHandler after finalization
      and report errors on merge.
      
      Bug: v8:10314
      Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
  21. 10 Sep, 2019 1 commit
  22. 24 May, 2019 1 commit
  23. 23 May, 2019 3 commits
  24. 21 May, 2019 1 commit
  25. 15 Feb, 2019 1 commit
  26. 28 Nov, 2018 1 commit
  27. 09 Nov, 2018 1 commit
    • Clemens Hammacher's avatar
      Extract lambda tasks to task-utils.h · 578fe721
      Clemens Hammacher authored
      This extracts the lambda tasks to an own compilation unit and header
      file. Additionally, it addresses the TODO to avoid templates and just
      store the function to execute in an std::function.
      Third, it provides the same functionality for pure (non-cancellable
      non-idle) tasks.
      Last, it removes the "Lambda" part from the methods, because we can
      actually instantiate it with anything that is invocable (function
      pointer, lambda, functor, ...).
      
      R=ahaas@chromium.org
      
      Bug: v8:8238
      Change-Id: I2f613f5b15ee208f215bbf74bd6d1d41889fd637
      Reviewed-on: https://chromium-review.googlesource.com/c/1328923
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57397}
      578fe721
  28. 31 Oct, 2018 3 commits
  29. 15 Oct, 2018 1 commit
  30. 12 Oct, 2018 1 commit