1. 19 Feb, 2020 2 commits
    • Seth Brenith's avatar
      Revert "[torque] Support bitfield structs stored within Smis" · 4dc1fb4e
      Seth Brenith authored
      This reverts commit e5e4ea96.
      
      Reason for revert: mysterious performance regression chromium:1052756
      
      Original change's description:
      > [torque] Support bitfield structs stored within Smis
      >
      > This change moves the definition of the bits stored in DebugInfo::flags
      > to Torque, and updates the only Torque usage of that field to use more
      > natural syntax. This is intended as an example of common patterns found
      > in various other classes. Several supporting changes are required:
      >
      > 1. Add a new type representing a bitfield struct stored within a Smi. It
      >    is currently called SmiTagged, but I'm open to suggestions.
      > 2. Add an enum-style output for Torque bitfield structs whose bitfields
      >    occupy only one bit each.
      > 3. Add a new case to MachineOperatorReducer that makes the generated
      >    code for IncBlockCounter match with what was generated before this
      >    change.
      > 4. Add support for reporting these bitfields in the postmortem debugging
      >    API. The format matches existing bitfields but with an offset value
      >    that includes the SMI shift size.
      >
      > Bug: v8:7793
      > Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66182}
      
      Bug: chromium:1052756, v8:7793
      Change-Id: I9e2897efbb6321124bf4952cf09de2f179f7310d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062569
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66349}
      4dc1fb4e
    • Andreas Haas's avatar
      [wasm] The name of a custom section can cause a validation error · 03d5a7ba
      Andreas Haas authored
      The WebAssembly spec defines that the name of a custom section can cause
      a validation error. The streaming decoder, however, used a separate
      Decoder object to decode the name, and thereby avoided a validation
      error. With this CL the streaming decoder uses the main decoder to
      decode the name of the custom section.
      
      In addition this CL removes the test mjsunit/regress/wasm/regress-789952.
      This test defined an invalid WebAssembly module and expected it to
      compile. As it is a regression test, it makes no sense to fix the test.
      The module is invalid because it defines the length of the custom section
      to be '0', so there are no bytes in the custom section for its name.
      
      R=clemensb@chromium.org
      CC=thibaudm@chromium.org
      
      Bug: v8:10126
      Change-Id: I8cfc77c9a5916570d5362d5922e0179a29774da8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041446
      Commit-Queue: Andreas Haas <ahaas@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66348}
      03d5a7ba
  2. 17 Feb, 2020 1 commit
  3. 14 Feb, 2020 1 commit
  4. 13 Feb, 2020 1 commit
  5. 12 Feb, 2020 3 commits
  6. 07 Feb, 2020 3 commits
  7. 06 Feb, 2020 1 commit
    • Ulan Degenbaev's avatar
      [ptr-compr, heap] Use system pointer size for heap limit computation · 8732596c
      Ulan Degenbaev authored
      A pointer-compressed heap has the same heap limit heuristics as a 32-bit
      heap. Specifically, the heap limit is restricted to 1GB due to scarce
      virtual addresses space on 32-bit platforms. That limitation does not
      apply for pointer-compressed heaps which can use 4GB.
      
      This CL changes the heap limit computation to use system the pointer
      size instead of the tagged pointer size. Note that the young generation
      limit continues to use the tagged pointer size.
      
      Bug: chromium:1045034
      Change-Id: I9d5bb818c32a82322476e9c97feee331400ebe0f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042102Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66159}
      8732596c
  8. 04 Feb, 2020 1 commit
    • 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
  9. 30 Jan, 2020 2 commits
  10. 28 Jan, 2020 1 commit
    • Philip Pfaffe's avatar
      Improve iterator_range to take non-&& arguments · c51c9f7c
      Philip Pfaffe authored
      The current implementation takes forwarding reference arguments, which
      is fine when you call it with rvalues, like
      make_iterator_range(V.begin(), V.end()). If you call it with lvalues
      though, it doesn't do what you'd expect. ForwardIterator becomes a
      reference:
      
      Foo I = V.begin();
      make_iterator_range(I, I); //ForwardIterator is deduced as Foo&
      
      Since iterator are supposed to be small, no harm in passing them by
      value.
      
      Change-Id: I151c87304949d810c72c42f60e9d1a7151f61f83
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020780
      Commit-Queue: Philip Pfaffe <pfaffe@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66007}
      c51c9f7c
  11. 24 Jan, 2020 2 commits
  12. 23 Jan, 2020 1 commit
  13. 22 Jan, 2020 5 commits
  14. 21 Jan, 2020 1 commit
  15. 20 Jan, 2020 6 commits
  16. 17 Jan, 2020 1 commit
  17. 16 Jan, 2020 5 commits
  18. 15 Jan, 2020 2 commits
    • Emanuel Ziegler's avatar
      [wasm][reference-types] Enable ref.null in Wasm code · ea696362
      Emanuel Ziegler authored
      Add decoding of ref.null as a valid argument for references in
      TurboFan, LiftOff and the interpreter.
      
      R=ahaas@chromium.org
      R=jkummerow@chromium.org
      
      Bug: chromium:10063
      Change-Id: I1e2d9c76f616dacb3aa06f8b535543bdcdcf0783
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991485
      Commit-Queue: Emanuel Ziegler <ecmziegler@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65788}
      ea696362
    • 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
  19. 14 Jan, 2020 1 commit