1. 16 Dec, 2019 1 commit
  2. 04 Dec, 2019 2 commits
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored
      This patch implements inspector support for private instance methods:
      
      - Previously to implement brand checking for instances with private
        instance methods we store the brand both as the value with the brand
        itself as the key in the stances. Now we make the value the context
        associated with the class instead.
      - To retrieve the private instance methods and accessors from the
        instances at runtime, we look into the contexts stored with the
        brands, and analyze the scope info to get the names as well as
        context slot indices of them.
      - This patch extends the `PrivatePropertyDescriptor` in the inspector
        protocol to include optional `get` and `set` fields, and make the
        `value` field optional (similar to `PropertyDescriptor`s).
        Private fields or private instance methods are returned in the
        `value` field while private accessors are returned in the `get`
        and/or `set` field. Property previews for the instaces containing
        private instance methods and accessors are also updated similarly,
        although no additional protocol change is necessary since the
        `PropertyPreview` type can already be used to display accessors.
      
      Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
      
      Bug: v8:9839, v8:8330
      Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
    • Leszek Swirski's avatar
      [isolate] Revert oddball checks to non-const Isolate* · 29af4273
      Leszek Swirski authored
      Looks like even the small amount of logic needed to extract ReadOnlyRoots
      from a const Isolate* (e.g. a HeapObject check) is enough to cause
      regressions.
      
      Revert these predicates to take non-const Isolate*, while keeping const
      Isolate* elsewhere. If we ever need const Isolate* for the oddball
      predicates, we can add it in addition to the non-const one.
      
      Bug: chromium:1029457
      Bug: chromium:1030001
      Bug: chromium:1030003
      Bug: chromium:1030102
      Change-Id: Ia6fa45f282a1a1961c0afa8ed973baebf6fbafd3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1948721Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Commit-Queue: Igor Sheludko <ishell@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65331}
      29af4273
  3. 27 Nov, 2019 1 commit
    • Leszek Swirski's avatar
      [isolate] Make field getters use a const Isolate* · 42a56e03
      Leszek Swirski authored
      To indicate that the Isolate* in getters might not be a "real" isolate,
      but rather a calculated one from GetIsolateForPtrCompr only used for
      calculating the isolate root, make that function return a const Isolate*
      and change field getters, Object::IsFoo predicates, and related
      functions to all take a const Isolate* instead of an Isolate*
      
      With this change, we can slightly more confidently use Objects that are
      in OffThreadSpace, without having to worry too much about having an
      Isolate* floating around that could accidentally be used.
      
      This is a slight abuse of const semantics, but it allows implicit
      conversion from Isolate* arguments to the const Isolate* parameter.
      
      Bug: v8:7703
      Bug: chromium:1011762
      Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65199}
      42a56e03
  4. 26 Nov, 2019 1 commit
  5. 21 Nov, 2019 1 commit
  6. 20 Nov, 2019 2 commits
  7. 19 Nov, 2019 1 commit
  8. 15 Nov, 2019 2 commits
  9. 12 Nov, 2019 1 commit
  10. 11 Nov, 2019 2 commits
  11. 06 Nov, 2019 2 commits
  12. 05 Nov, 2019 3 commits
  13. 01 Nov, 2019 1 commit
  14. 31 Oct, 2019 2 commits
  15. 30 Oct, 2019 2 commits
  16. 29 Oct, 2019 1 commit
    • Clemens Backes's avatar
      [wasm][debug] Fix location computation from interpreted frames · 700f9b0e
      Clemens Backes authored
      The {IsWasmFrame} check in {ComputeLocationFromStackTrace} only returned
      true for compiled frames, but not for interpreted ones. Thus, for
      interpreted frames we would run into the code for JS frames, which
      assumes that a {JSFunction} is available.
      
      This CL fixes this issue by renaming {IsWasmFrame} to
      {IsWasmCompiledFrame}, and introducing a new {IsWasmFrame} method which
      returns true for both compiled and interpreted frames.
      
      R=mstarzinger@chromium.org
      
      Bug: chromium:1018227
      Change-Id: If83b4129edaad775a212ccb741f3c62eabc2addb
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883892Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64607}
      700f9b0e
  17. 28 Oct, 2019 3 commits
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored
      This change begins making use of the fact that Torque now knows about
      the relationship between classes and instance types, to replace a few
      repetitive lists:
      
      - Instance type checkers (single and range), defined in
        src/objects/instance-type.h
      - Verification dispatch in src/diagnostics/objects-debug.cc
      - Printer dispatch in src/diagnostics/objects-printer.cc
      - Postmortem object type detection in
        tools/debug_helper/get-object-properties.cc
      
      Torque is updated to generate four macro lists for the instance types,
      representing all of the classes separated in two dimensions: classes
      that correspond to a single instance type versus those that have a
      range, and classes that are fully defined in Torque (with fields and
      methods inside '{}') versus those that are only declared. The latter
      distinction is useful because fully-defined classes are guaranteed to
      correspond to real C++ classes, whereas only-declared classes are not.
      
      A few other changes were required to make the lists above work:
      
      - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
        and avoid conflicts with the new macro-generated IsFiller method. This
        is the part I'm most worried about: I think the new name is an
        improvement for clarity and consistency, but I could imagine someone
        typing IsFiller out of habit and introducing a bug. If we'd prefer to
        keep the name IsFiller, my other idea is to rename FreeSpace to
        VariableSizeFiller and Filler to FixedSizeFiller.
      - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
        expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
      - Normalized the dispatched behavior for BigIntBase and HeapNumber.
      - Added a few new object printers.
      
      Bug: v8:7793
      Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
    • Mythri A's avatar
      [ic] Correctly Handle global loads when global object has proxies · 14885d58
      Mythri A authored
      When global object has proxies we should first call hasProperty and
      then call GetProperty according to spec. This cl fixes both
      LoadGlobal and LoadLookupGlobal to correctly handle these cases.
      
      Also fixes tests that didn't expect hasProperty to be called.
      
      Change-Id: I3a45df7ae24be74dd46cf04cafbf8c2d7018b3af
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876059
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64580}
      14885d58
    • Victor Gomes's avatar
      [runtime] Remove unused bit in Context and rename HasContextExtension · c2135c79
      Victor Gomes authored
      A bit was added in the context length slot to indicate if
      the context had an extension slot. It turns out that
      we need this information much earlier and so this flag is now
      in the scope info instead.
      
      This CL removes this bit from length, since it was not
      used anymore.
      
      I also renamed HasContextExtension to HasContextExtensionSlot
      to differentiate from Context::has_extension which returns
      true only if the context has an extension slot and the
      extension is not the undefined object.
      
      Bug: v8:9744
      Change-Id: I7c37105b7afed34e8f480a64596fab285388f21b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879935
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64577}
      c2135c79
  18. 22 Oct, 2019 1 commit
  19. 21 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      [regexp] Add a backtracking limit in the interpreter · 48756fcf
      Jakob Gruber authored
      V8 uses a backtracking regexp engine, which has the caveat that some
      regexp patterns can have exponential runtime behavior when excessive
      backtracking is involved.
      
      Especially when regexp patterns are user-controlled, it would be useful
      to be able to set an upper limit for a single regexp execution. This CL
      takes an initial step in that direction by adding a backtracking limit
      (intended to approximate execution time):
      
      - The limit is stored in the JSRegExp's data array.
      - A limit can currently only be set through the %NewRegExpWithLimit
      runtime function.
      - The limit is applied during interpreter execution. When exceeded, the
      interpreter stops execution and returns FAILURE (even if continued
      execution would at some later point have resulted in SUCCESS).
      
      In follow-up CLs, this mechanism will be extended to work in jitted
      regexp code, and exposed through the V8 API.
      
      Bug: v8:9695
      Change-Id: Iadb5c100052f4a63b26f1ec49cf97c6713a66b9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864934
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64417}
      48756fcf
  20. 16 Oct, 2019 2 commits
  21. 11 Oct, 2019 2 commits
  22. 08 Oct, 2019 2 commits
  23. 07 Oct, 2019 1 commit
  24. 26 Sep, 2019 2 commits
  25. 18 Sep, 2019 1 commit