1. 27 Sep, 2021 1 commit
  2. 16 Sep, 2021 1 commit
  3. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored
      This is a reland of d1b27019
      
      Fixes include:
      Adding missing file to bazel build
      Forward-declaring classing before friend-classing them to fix win/gcc
      Add missing v8-isolate.h include for vtune builds
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
      Bug: v8:11965
      Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  4. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored
      This reverts commit d1b27019.
      
      Reason for revert: Broke vtune build, tsan build and possibly others
      
      Original change's description:
      > [include] Split out v8.h
      >
      > This moves every single class/function out of include/v8.h into a
      > separate header in include/, which v8.h then includes so that
      > externally nothing appears to have changed.
      >
      > Every include of v8.h from inside v8 has been changed to a more
      > fine-grained include.
      >
      > Previously inline functions defined at the bottom of v8.h would call
      > private non-inline functions in the V8 class. Since that class is now
      > in v8-initialization.h and is rarely included (as that would create
      > dependency cycles), this is not possible and so those methods have been
      > moved out of the V8 class into the namespace v8::api_internal.
      >
      > None of the previous files in include/ now #include v8.h, which means
      > if embedders were relying on this transitive dependency then it will
      > give compile failures.
      >
      > v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      > that Chrome continue to compile but that change will be reverted once
      > those transitive #includes in chrome are changed to include it directly.
      >
      > Full design:
      > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      >
      > Bug: v8:11965
      > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Camillo Bruni <cbruni@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Cr-Commit-Position: refs/heads/main@{#76424}
      
      Bug: v8:11965
      Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Owners-Override: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored
      This moves every single class/function out of include/v8.h into a
      separate header in include/, which v8.h then includes so that
      externally nothing appears to have changed.
      
      Every include of v8.h from inside v8 has been changed to a more
      fine-grained include.
      
      Previously inline functions defined at the bottom of v8.h would call
      private non-inline functions in the V8 class. Since that class is now
      in v8-initialization.h and is rarely included (as that would create
      dependency cycles), this is not possible and so those methods have been
      moved out of the V8 class into the namespace v8::api_internal.
      
      None of the previous files in include/ now #include v8.h, which means
      if embedders were relying on this transitive dependency then it will
      give compile failures.
      
      v8-inspector.h does depend on v8-scripts.h for the time being to ensure
      that Chrome continue to compile but that change will be reverted once
      those transitive #includes in chrome are changed to include it directly.
      
      Full design:
      https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
      
      Bug: v8:11965
      Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  5. 16 Aug, 2021 1 commit
  6. 22 Jun, 2021 1 commit
  7. 18 Jun, 2021 1 commit
  8. 14 Jun, 2021 1 commit
  9. 07 Jun, 2021 1 commit
  10. 01 Jun, 2021 1 commit
  11. 30 Apr, 2021 1 commit
    • Jakob Kummerow's avatar
      [cctest] Make sure FLAG_stack_size settings have effect · a43f3818
      Jakob Kummerow authored
      Using the default cctest TEST(...) macro causes later writes to
      FLAG_stack_size to have no effect, because the StackGuard reads
      that flag's value during Isolate initialization, which is done
      before the test body is executed. This patch changes the two
      existing tests that accidentally did this to UNINITIALIZED_TEST,
      putting them in charge of Isolate creation, thereby ensuring that
      the intended stack size is configured correctly.
      
      Change-Id: Ib030795ef46f23d576f6dbbd26b347ac804b5085
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862778Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#74309}
      a43f3818
  12. 16 Mar, 2021 1 commit
  13. 09 Mar, 2021 1 commit
  14. 03 Mar, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Instantiate accessors only once. · e9873bf1
      Benedikt Meurer authored
      When retrieving an API accessor function (i.e. either the getter or the
      setter) for which the lazy accessor mechanism is used (i.e. where the
      actual JSFunction is created lazily and only the FunctionTemplateInfo)
      is around, we thus far created a fresh JSFunction every time the
      accessor function is requested, but that's observably wrong behavior,
      since the accessors are JavaScript objects with identity. We currently
      rely on the instantiation cache to guarantee identity, but there's no
      reason why we couldn't instead just put the instantiated JSFunction into
      the AccessorPair.
      
      Fixing this to only instantiate the lazy accessor pair only once, upon
      first time it's requested, coincidentally also simplifies (and fixes)
      the API accessor breakpoint machinery. This was previously lacking
      support for walking dictionary prototype objects and forcibly
      instantiating the lazy accessor pairs with break points. However, all
      this magic in the debugger is no longer necessary when we ensure that
      the lazy accessor pair component is generally only instantiated once.
      
      Bug: v8:178, v8:7596, chromium:986063, chromium:496666
      Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
      Fixed: chromium:1163547
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73163}
      e9873bf1
  15. 14 Jan, 2021 1 commit
  16. 24 Nov, 2020 1 commit
  17. 20 Nov, 2020 1 commit
  18. 12 Nov, 2020 1 commit
  19. 28 Sep, 2020 1 commit
    • Alex Kodat's avatar
      [debug] Restore StepNext on correct frame for RestoreDebug · 9329f558
      Alex Kodat authored
      When an Isolate in a multi-threaded environment is being debugged
      and a thread does a Step Over (StepNext internally) one-shot
      breaks are created in the code at the stack frame where the
      StepNext occurred. However, if the stepped-over statement had
      a function call and the called function (or some function that
      it called) unlocked the Isolate (via a C++ function call) and
      another thread then locked the Isolate, an ArchiveDebug would
      be done which would save the fact that a StepNext is active and
      the call frame depth of the StepNext. The one-shot breaks would
      then be cleared to avoid stopping the now running thread.
      
      When the original thread that did the StepNext relocks the Isolate,
      a RestoreDebug is done which, seeing that a StepNext was active
      calls PrepareDebug which assumes that the StepNext must be for
      the current JS frame which is usually correct, but not in this
      case. This results in the StepNext break actually occurring in the
      function that called the C++ function not in the function where
      the StepNext was originally done. In addition, the function where
      the break now happens must necessarily be deoptimized if
      optimized, and debug code and a source map table created if one
      doesn't already exists though this is largely invisible to the
      user.
      
      Occasionally, a crash/core dump also occurs because the stack
      guard is restored after the debugging environment is restored in
      the RestoreThread code which can prevent the compiler from being
      called to generate the source map table (for the incorrect
      function) since the stack guard is another thread's stack guard,
      and so might appear that the stack guard has been gone past so
      the compiler is not called, resulting in there being no source
      map table. But PrepareStep ends up calling the BreakIterator
      (via the DebugInfo constructor) which assumes there is a source
      map table so we get a crash.
      
      The fix is to have PrepareStep to skip to the frame where the
      StepNext was done before doing its thing. Since the only
      PrepareStepcaller that requires a frame other than the current
      frame, is RestoreDebug, a target frame parameter was added to
      PrepareStep that's set by RestoreDebug and defaults to -1
      indicating to use the current frame for all other callers.
      
      While this made the order of the debug environment and stack
      guard no longer cause an obvious problem, it still felt wrong
      to defer restoration of the stack guard until after something
      as potentially complex as PrepareStep might be called, so the
      order of RestoreDebug and RestoreStackGuard calls were reversed.
      
      Bug: v8:10902
      Change-Id: I174e254e72414c827e113aec142f1d329ebe73d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405932
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70152}
      9329f558
  20. 22 Sep, 2020 1 commit
  21. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  22. 29 Apr, 2020 1 commit
  23. 09 Mar, 2020 2 commits
  24. 11 Feb, 2020 1 commit
  25. 03 Feb, 2020 1 commit
    • Sigurd Schneider's avatar
      [debugger] Allow termination-on-resume when paused at a breakpoint · 9e52d5c5
      Sigurd Schneider authored
      This CL implements functionality to allow an embedder to mark a
      debug scope as terminate-on-resume. This results in a termination
      exception when that debug scope is left and execution is resumed.
      Execution of JavaScript remains possible after a debug scope is
      marked as terminate-on-resume (but before execution of the paused
      code resumes).
      This is used by blink to correctly prevent resuming JavaScript
      execution upon reload while being paused at a breakpoint.
      
      This is important for handling reloads while paused at a breakpoint
      in blink. The resume command terminates blink's nested message loop
      that is used while to keep the frame responsive while the debugger
      is paused. But if a reload is triggered while execution is paused
      on a breakpoint, but before execution is actually resumed from the
       breakpoint (that means before returning into the V8 JavaScript
      frames that are paused on the stack below the C++ frames that belong
      to the nested message loop), we re-enter V8 to do tear-down actions
      of the old frame. In this case Runtime.terminateExecution() cannot be
      used before Debugger.resume(), because the tear-down actions that
      re-enter V8 would trigger the termination exception and crash the
      browser (because the browser expected the tear-down to succeed).
      
      Hence we introduce this flag on V8 that says: It is OK if someone
      re-enters V8 (to execute JS), but upon resuming from the breakpoint
      (i.e. returning to the paused frames that are on the stack below),
      generate a termination exception.
      
      We deliberated adding a corresponding logic on the blink side (instead
      of V8) but we think this is the simplest solution.
      
      More details in the design doc:
      
      https://docs.google.com/document/d/1aO9v0YhoKNqKleqfACGUpwrBUayLFGqktz9ltdgKHMk
      
      Bug: chromium:1004038, chromium:1014415
      
      Change-Id: I896692d4c21cb0acae89c1d783d37ce45b73c113
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1924366
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66084}
      9e52d5c5
  26. 04 Dec, 2019 1 commit
    • 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
  27. 22 Oct, 2019 1 commit
  28. 16 Oct, 2019 1 commit
    • Simon Zünd's avatar
      Reland "Unconditionally enable snapshot builds and remove 'v8_use_snapshot'" · 69efc4c3
      Simon Zünd authored
      This is a reland of 1c56974f
      
      This is a plain reland of the original CL. The original CL was speculatively
      reverted, but ended up not being the cause for bot failures.
      
      Original change's description:
      > Unconditionally enable snapshot builds and remove 'v8_use_snapshot'
      >
      > This CL removes 'v8_use_snapshot' and the usages of the implied
      > V8_USE_SNAPSHOT define. One test runner unittest was updated to use the
      > "asan" variant instead of the now obsolete "no_snap" variant.
      >
      > Related chromium CL: https://crrev.com/c/1796325.
      >
      > Bug: v8:8531
      > Change-Id: I5da7c9f8e9110fe7bc0f4e4f821bcb7f7d98f927
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784282
      > Commit-Queue: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Tamer Tas <tmrts@chromium.org>
      > Reviewed-by: Michael Achenbach <machenbach@chromium.org>
      > Reviewed-by: Nico Weber <thakis@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64290}
      
      TBR=thakis@chromium.org,machenbach@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tmrts@chromium.org,szuend@chromium.org
      
      Bug: v8:8531
      Change-Id: Id75a802279238138f7aefec62e0b6425a5acc08d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864649Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64305}
      69efc4c3
  29. 15 Oct, 2019 2 commits
  30. 02 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Remove JS natives support, step 1 · 28a9dc2b
      Jakob Gruber authored
      The natives blob is deprecated and will be removed in the next
      release.
      
      This commit does two things, 1. it disables the v8_extra_library_files
      gn argument which will make building natives_blob.bin through gn
      impossible; 2. it marks API functions associated with the natives blob
      as V8_DEPRECATE_SOON.
      
      Embedders should remove any uses of SetNativesDataBlob and replace all
      calls to
      
       InitializeExternalStartupData(const char*, const char*)
      
      with the new function
      
       InitializeExternalStartupDataFromFile(const char*)
      
      Step 2 is to mark API functions as V8_DEPRECATED.
      Step 3, in the next V8 release, is to remove these functions and all
      other natives support in V8.
      
      Bug: v8:7624
      Change-Id: I745e96c60204a9b94d9240be65dd59bb9bdd0699
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1824944
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64080}
      28a9dc2b
  31. 11 Sep, 2019 1 commit
  32. 10 Sep, 2019 1 commit
  33. 28 Aug, 2019 1 commit
  34. 26 Aug, 2019 1 commit
  35. 23 Aug, 2019 1 commit
  36. 22 Aug, 2019 2 commits