1. 06 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [runtime] Move string table off-heap · 1546be9c
      Leszek Swirski authored
      Changes the isolate's string table into an off-heap structure. This
      allows the string table to be resized without allocating on the V8 heap,
      and potentially triggering a GC. This allows existing strings to be
      inserted into the string table without requiring allocation.
      
      This has two important benefits:
      
        1) It allows the deserializer to insert strings directly into the
           string table, rather than having to defer string insertion until
           deserialization completes.
      
        2) It simplifies the concurrent string table lookup to allow resizing
           the table inside the write lock, therefore eliminating the race
           where two concurrent lookups could both resize the table.
      
      The off-heap string table has the following properties:
      
        1) The general hashmap behaviour matches the HashTable, i.e. open
           addressing, power-of-two sized, quadratic probing. This could, of
           course, now be changed.
      
        2) The empty and deleted sentinels are changed to Smi 0 and 1,
           respectively, to make those comparisons a bit cheaper and not
           require roots access.
      
        3) When the HashTable is resized, the old elements array is kept
           alive in a linked list of previous arrays, so that concurrent
           lookups don't lose the data they're accessing. This linked list
           is cleared by the GC, as then we know that all threads are in
           a safepoint.
      
        4) The GC treats the hash table entries as weak roots, and only walks
           them for non-live reference clearing and for evacuation.
      
        5) Since there is no longer a FixedArray to serialize for the startup
           snapshot, there is now a custom serialization of the string table,
           and the string table root is considered unserializable during weak
           root iteration. As a bonus, the custom serialization is more
           efficient, as it skips non-string entries.
      
      As a drive-by, rename LookupStringExists_NoAllocate to
      TryStringToIndexOrLookupExisting, to make it clearer that it returns
      a non-string for the case when the string is an array index. As another
      drive-by, extract StringSet into a separate header.
      
      Bug: v8:10729
      Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69270}
      1546be9c
  2. 31 Jul, 2020 1 commit
    • Dan Elphick's avatar
      [heap] Share RO_SPACE pages with pointer compression · c7d22c49
      Dan Elphick authored
      This allows the configuration v8_enable_shared_ro_heap and
      v8_enable_pointer_compression on Linux and Android, although it still
      defaults to off.
      
      When pointer compression and read-only heap sharing are enabled, sharing
      is achieved by allocating ReadOnlyPages in shared memory that are
      retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are
      then remapped into the address space of the Isolate ultimately using
      mremap.
      
      To simplify the creation process the ReadOnlySpace memory for the first
      Isolate is created as before without any sharing. It is only when the
      ReadOnlySpace memory has been finalized that the shared memory is
      allocated and has its contents copied into it. The original memory is
      then released (with PC this means it's just released back to the
      BoundedPageAllocator) and immediately re-allocated as a shared mapping.
      
      Because we would like to make v8_enable_shared_ro_heap default to true
      at some point but can't make this conditional on the value returned by
      a method in the code we are yet to compile, the code required for
      sharing has been mostly changed to use ifs with
      ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where
      a compile error would result due to the absence of a class members
      without sharing. IsReadOnlySpaceShared() will evaluate
      CanAllocateSharedPages in the platform PageAllocator (with pointer
      compression and sharing enabled) once and cache that value so sharing
      cannot be toggled during the lifetime of the process.
      
      Bug: v8:10454
      Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69174}
      c7d22c49
  3. 23 Jul, 2020 1 commit
  4. 22 Jul, 2020 2 commits
  5. 09 Jul, 2020 2 commits
  6. 03 Jul, 2020 1 commit
    • Dan Elphick's avatar
      [ptr-compr] Get Isolate via object address · a3de69da
      Dan Elphick authored
      To get the Isolate from a HeapObject, rather than masking off the
      MemoryChunk and then loading the heap from the MemoryChunk (which won't
      work when RO_SPACE is shared between Isolates), get the Isolate by
      masking off the bottom 32 bits and apply the Isolate bias.
      
      Also fixes up a stale comment and makes several methods in RootsTable
      and Isolate const to support this change.
      
      Bug: v8:10454
      Change-Id: I5f8eb873d8486b699460223dbe3454a5dcf1854f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2280088
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68671}
      a3de69da
  7. 29 Jun, 2020 1 commit
  8. 26 Jun, 2020 2 commits
    • Shu-yu Guo's avatar
      Revert "[wasm-gc] Implement rtt.sub" · 30456566
      Shu-yu Guo authored
      This reverts commit 04ce88ea.
      
      Reason for revert: TSAN failure: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/32135
      
      Original change's description:
      > [wasm-gc] Implement rtt.sub
      > 
      > RTTs are internally represented as Maps. To store supertype information,
      > this patch introduces a WasmTypeInfo object, which is installed on Wasm
      > objects' Maps and points at both the off-heap type information and the
      > parent RTT.
      > In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      > that the proposal requires will be implemented later.
      > 
      > Bug: v8:7748
      > Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#68564}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,tebbi@chromium.org
      
      Change-Id: I311732e1ced4de7a58b87d4a9b6056e0d62aa986
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7748
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2270734Reviewed-by: 's avatarShu-yu Guo <syg@chromium.org>
      Commit-Queue: Shu-yu Guo <syg@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68567}
      30456566
    • Jakob Kummerow's avatar
      [wasm-gc] Implement rtt.sub · 04ce88ea
      Jakob Kummerow authored
      RTTs are internally represented as Maps. To store supertype information,
      this patch introduces a WasmTypeInfo object, which is installed on Wasm
      objects' Maps and points at both the off-heap type information and the
      parent RTT.
      In this patch, rtt.sub always creates a fresh RTT. The canonicalization
      that the proposal requires will be implemented later.
      
      Bug: v8:7748
      Change-Id: I8286dd11f520966155cd95c2bd844ec34fccd131
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260566
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68564}
      04ce88ea
  9. 23 Jun, 2020 1 commit
    • Daniel Clifford's avatar
      [torque] generate Cast<> macros from Torque-defined classes · 1052dfb3
      Daniel Clifford authored
      This change enables automatic generation of Cast<> operators for
      classes that are defined in Torque.
      
      * Cast<> macros are generated for all classes that are defined in
        Torque code that are neither shapes nor marked with a new
        @doNotGenerateCast annotation.
      
      * Implicitly generated Cast macros simply call through to an
        internally-defined "DownCastForTorqueClass" macro that implements
        the cast using one of three strategies for efficiency. If the class
        has subclasses (i.e. a range of instance types including subtypes),
        the DownCastForTorqueClass checks for inclusion in the instance type
        range. If the class has a single instance type (i.e. no subclasses),
        then either 1) a map check is used if the class has a globally-
        defined map constant or 2) an equality check for the instance type
        is used.
      
      * Added new intrinsics to introspect class information, e.g. fetching
        instance type ranges for a class, accessing the globally-defined map
        for a class.
      
      * Removed a whole pile of existing explicit Cast<> operators that are
        no longer needed because of the implicitly generated Cast<> macros.
      
      * Added tests for the new Cast<> implementations.
      
      Bug: v8:7793
      Change-Id: I3aadb0c62b720e9de4e7978b9ec4f05075771b8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2250239
      Commit-Queue: Daniel Clifford <danno@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68478}
      1052dfb3
  10. 25 May, 2020 1 commit
  11. 21 May, 2020 1 commit
    • Seth Brenith's avatar
      [diagnostics] Support --turbo-profiling for builtins · 18c73676
      Seth Brenith authored
      Currently, if d8 is run with the --turbo-profiling flag, it prints info
      about every TurboFan-compiled function. This info includes the number of
      times that each basic block in the function was run. It also includes
      text representations of the function's schedule and code, so that the
      person reading the output can associate counters with blocks of code.
      
      The data about each function is currently stored in a
      BasicBlockProfiler::Data instance, which is attached to a list owned by
      the singleton BasicBlockProfiler. Each Data contains an
      std::vector<uint32_t> which represents how many times each block in the
      function has executed. The generated code for each block uses a raw
      pointer into the storage of that vector to implement incrementing the
      counter.
      
      With this change, if you compile with v8_enable_builtins_profiling and
      then run with --turbo-profiling, d8 will print that same info about
      builtins too.
      
      In order to generate code that can survive being serialized to a
      snapshot and reloaded, this change uses counters in the JS heap instead
      of a std::vector outside the JS heap. The steps for instrumentation are
      as follows:
      
      1. Between scheduling and instruction selection, add code to increment
         the counter for each block. The counters array doesn't yet exist at
         this point, and allocation is disallowed, so at this point the code
         refers to a special marker value.
      2. During finalization of the code, allocate a BasicBlockProfilingData
         object on the JS heap containing data equivalent to what is stored in
         BasicBlockProfiler::Data. This includes a ByteArray that is big
         enough to store the counters for each block.
      3. Patch the reference in the BuiltinsConstantsTableBuilder so that
         instead of referring to the marker object, it now refers to this
         ByteArray. Also add the BasicBlockProfilingData object to a list that
         is attached to the heap roots so it can be easily accessed for
         printing.
      
      Because these steps include modifying the BuiltinsConstantsTableBuilder,
      this procedure is only applicable to builtins. Runtime-generated code
      still uses raw pointers into std::vector instances. In order to keep
      divergence between these code paths to a minimum, most work is done
      referring to instances of BasicBlockProfiler::Data (the C++ class), and
      functions are provided to copy back and forth between that type and
      BasicBlockProfilingData (the JS heap object).
      
      This change is intended only to make --turbo-profiling work consistently
      on more kinds of functions, but with some further work, this data could
      form the basis for:
      - code coverage info for fuzzers, and/or
      - hot-path info for profile-guided optimization.
      
      Bug: v8:10470, v8:9119
      Change-Id: Ib556a5bc3abe67cdaa2e3ee62702a2a08b11cb61
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2159738
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67944}
      18c73676
  12. 14 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add off thread deserialization · 595609fb
      Leszek Swirski authored
      Add a new OffThreadObjectDeserializer, which can deserialize a snapshot
      into an OffThreadIsolate.
      
      This involves templating the Deserializer base class on Isolate, and
      amending OffThreadHeap to be able to create Reservations same as the
      main-thread Heap can. Various off-thread incompatible methods are
      stubbed out as UNREACHABLE in OffThreadIsolate overloads.
      
      There is currently no API entry into the off-thread deserialization, but
      under --stress-background-compile it now runs the CodeDeserializer (i.e.
      code cache deserialization) in a background thread.
      
      Bug: chromium:1075999
      
      Change-Id: I2453f51ae31df4d4b6aa94b0804a9d6d3a03781e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172741
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67799}
      595609fb
  13. 13 May, 2020 1 commit
  14. 12 May, 2020 1 commit
  15. 08 May, 2020 1 commit
  16. 07 May, 2020 1 commit
  17. 06 May, 2020 2 commits
  18. 04 May, 2020 1 commit
  19. 28 Apr, 2020 1 commit
  20. 20 Apr, 2020 1 commit
  21. 08 Apr, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] remove HasIndexedField and cleanup internal class lists · 25808bbc
      Tobias Tebbi authored
      The two refactorings are somewhat orthogonal, but intersect at the
      class and instance type list generation, which is why it's easier to
      put them in one CL.
      
      For the removal of HasIndexedField, the removal is motivated by the
      fact that is no longer necessary, and that using a flag to store this
      kind of information is hacky.
      
      For the class list changes, this is a cleanup in that we no longer
      generate third-order macros, but instead normal macro lists.
      There is a functional change and bug-fix in that we no longer include
      abstract classes in lists that refer to instance types or maps. It's
      still somewhat broken though, so I can't test abstract internal classes
      yet, though. Coming in a follow-up CL.
      
      TBR=ulan@chromium.org
      
      Bug: v8:7793
      Change-Id: Ided8591370570ca3810d7991f53177ca32e03048
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108034
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67056}
      25808bbc
  22. 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
  23. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored
      This allows CoverageInfo to be distinguished from other kinds of
      FixedArray at runtime. I also updated it to use untagged data since it
      only stores ints, since that seems like the generally right thing to do
      (even though I doubt anybody allocates enough of these to notice the
      reduced GC work).
      
      Related Torque changes:
      - Allow structs containing untagged data to be used as class fields.
        This requires classifying them into the tagged or untagged sections of
        the class layout, and checking that their alignment requirements are
        met when stored in a packed array.
      - Generate a struct containing struct field offsets, so we can ensure
        that the layouts defined in Torque and C++ code match. Of course it
        would be nice to generate a lot more (indexed accessors, synchronized
        accessors, GC visitors, etc.), but we can't do it all at once.
      
      Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  24. 12 Feb, 2020 1 commit
  25. 10 Feb, 2020 1 commit
  26. 06 Feb, 2020 1 commit
  27. 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
  28. 24 Oct, 2019 1 commit
  29. 22 Oct, 2019 1 commit
  30. 17 Oct, 2019 1 commit
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      Toon Verwaest authored
      This is a reland of c7c47c68.
      
      This makes TSAN happy in addition to:
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
  31. 16 Oct, 2019 2 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      Sathya Gunasekaran authored
      This reverts commit c7c47c68.
      
      Reason for revert: breaks TSAN
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738
      
      Original change's description:
      > Reland "[runtime] Move Context::native_context to the map"
      > 
      > This is a reland of f05bae1e
      > 
      > Previously I presumed that the context read from a frame in the profiler was
      > a valid context. Turns out that on non-intel we're not guaranteed that the
      > frame is properly set up. In the case we looked at, the profiler took a
      > sample right before writing the frame marker indicating a builtin frame,
      > causing the "context" pointer from that frame to be a bytecode array. Since
      > we'll read random garbage on the stack as a possible context pointer, I made
      > the code reading the native context from it a little more defensive.
      > 
      > Bug: v8:9860
      > 
      > Original change's description:
      > > [runtime] Move Context::native_context to the map
      > >
      > > Remove the native context slot from contexts by making context maps
      > > native-context-specific. Now we require 2 loads to go from a context to the
      > > native context, but we have 1 field fewer to store when creating contexts.
      > >
      > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#64296}
      > 
      > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64314}
      
      TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
      
      Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9860
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      Toon Verwaest authored
      This is a reland of f05bae1e
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64314}
      c7c47c68
  32. 15 Oct, 2019 2 commits
  33. 23 Sep, 2019 1 commit
  34. 11 Sep, 2019 1 commit