Skip to content

V
V8
Switch branch/tag
  1. 01 Dec, 2020 1 commit
  3. 25 Nov, 2020 1 commit
  5. 17 Nov, 2020 1 commit
  7. 10 Mar, 2020 1 commit
  9. 03 Sep, 2019 1 commit
    • Jakob Kummerow's avatar
      Clean up thread initialization · c332eb9a
      Jakob Kummerow authored 
      This CL makes ThreadManager::InitThread *the* place that's responsible
for initializing metadata for a new thread, and ensures that all new
threads actually go through there. This was previously not the case,
and e.g. test-lockers/LockerUnlocker exposed a case where some threads
were trying to use another thread's simulator instance because the
ThreadLocalTop on the Isolate was in inconsistent state.

Change-Id: I302c643f420457f6ba73897fd45eb87969e1331c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1781688
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63527}
      c332eb9a
  11. 13 Aug, 2019 1 commit
  13. 12 Aug, 2019 1 commit
    • Jakob Gruber's avatar
      [isolate-data] Move the StackGuard to IsolateData · ef24a565
      Jakob Gruber authored 
      IsolateData guarantees a fixed root-relative offset for its contents,
thus allowing more efficient code generation for accesses to these
addresses. The stack limit, located within the StackGuard, is used by
all stack checks in CSA.

This CL moves the StackGuard inside IsolateData to make such efficient
loads of the limit possible.

Bug: v8:9595,v8:9534
Change-Id: I9abe26b88952709c88bf625cc6c028497815a58c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1741648Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63160}
      ef24a565
  15. 13 Jun, 2019 2 commits
  17. 24 May, 2019 1 commit
  19. 22 May, 2019 1 commit
  21. 07 May, 2019 1 commit
  23. 17 Apr, 2019 2 commits
    • Clemens Hammacher's avatar
      Reland "[wasm] Add stack guard for logging code" · 48635511
      Clemens Hammacher authored 
      This is a reland of 067ba2a0.
Unchanged reland, hence TBR.

Original change's description:
> [wasm] Add stack guard for logging code
>
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}

TBR=mstarzinger@chromium.org

Bug: v8:9104
Change-Id: I105b37ef8429d16ef5b983919ba8bca615e347c0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570017Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60899}
      48635511
    • Michael Hablich's avatar
      Revert "[wasm] Add stack guard for logging code" · 6ce63fd8
      Michael Hablich authored 
      This reverts commit 067ba2a0.

Reason for revert: blocks roll: https://chromium-review.googlesource.com/c/chromium/src/+/1570208

21:26:22.251 27507   # Fatal error in ../../v8/src/profiler/profile-generator.cc, line 19
21:26:22.251 27507   # Debug check failed: line > 0 (0 vs. 0).
21:26:22.251 27507   #
21:26:22.251 27507   #
21:26:22.251 27507   #
21:26:22.252 27507   #FailureMessage Object: 0x7ffe851046a0#0 0x56532cb371f9 base::debug::CollectStackTrace()
21:26:22.252 27507   #1 0x56532ca70863 base::debug::StackTrace::StackTrace()
21:26:22.252 27507   #2 0x56532e99610b gin::(anonymous namespace)::PrintStackTrace()
21:26:22.252 27507   #3 0x56532e989468 V8_Fatal()
21:26:22.252 27507   #4 0x56532e9891c5 v8::base::(anonymous namespace)::DefaultDcheckHandler()
21:26:22.252 27507   #5 0x56532b2bb876 v8::internal::SourcePositionTable::SetPosition()
21:26:22.252 27507   #6 0x56532b2c2268 v8::internal::ProfilerListener::CodeCreateEvent()
21:26:22.252 27507   #7 0x56532ae25275 v8::internal::(anonymous namespace)::LogFunctionCompilation()
21:26:22.252 27507   #8 0x56532ae26008 v8::internal::OptimizedCompilationJob::RecordFunctionCompilation()
21:26:22.252 27507   #9 0x56532ae32a08 v8::internal::Compiler::FinalizeOptimizedCompilationJob()
21:26:22.252 27507   #10 0x56532ae228eb v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions()
21:26:22.252 27507   #11 0x56532af14e4a v8::internal::StackGuard::HandleInterrupts()
21:26:22.252 27507   #12 0x56532b35f2ec v8::internal::__RT_impl_Runtime_StackGuard()
21:26:22.252 27507   #13 0x56532bba6720 <unknown>

Original change's description:
> [wasm] Add stack guard for logging code
> 
> Benchmarks or worker threads might never return to the event queue,
> hence they will never execute the scheduled foreground task to log
> compiled and published wasm code.
> This CL adds a stack guard to log the code, to ensure that we also log
> it for wasm code that never returns to the event queue.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: v8:9104
> Change-Id: I176959cadb4ab3a60153d0717530c032272ad3e8
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1561073
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60879}

TBR=mstarzinger@chromium.org,clemensh@chromium.org

Change-Id: I63dc56a41747caf683b14869a2d62017fd0301c1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9104
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1570012Reviewed-by: 's avatarMichael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60890}
      6ce63fd8
  25. 16 Apr, 2019 1 commit
  27. 04 Apr, 2019 1 commit
  29. 06 Mar, 2019 3 commits
    • Deepti Gandluri's avatar
      Reland "[wasm] Lazy update instances on a shared Memory.Grow" · 365b637c
      Deepti Gandluri authored 
      This is a reland of 80f06d6f

Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
> 
>  - Introduce a GROW_SHARED_MEMORY interrupt, and handler
>  - Memory objects for isolates are updated on a stack check, add
>    tracking for isolates that hit the stack check
>  - When enough memory is not reserved ahead of time, fail to grow
>  - Add tracking for externalized buffers in the MemoryTracker so
>    that the MemoryTracker will know when backing_stores can be freed.
>  - For shared buffer, do not always allocate a new buffer when
>    growing an externalized buffer
> 
> 
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}

Bug: v8:8564
Change-Id: Id0cf8e42a9d54ac702dba351e248a1b92713c98a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506357Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60071}
      365b637c
    • Bill Budge's avatar
      Revert "[wasm] Lazy update instances on a shared Memory.Grow" · e15bb0b3
      Bill Budge authored 
      This reverts commit 80f06d6f.

Reason for revert: failing grow-memory tests

Original change's description:
> [wasm] Lazy update instances on a shared Memory.Grow
> 
>  - Introduce a GROW_SHARED_MEMORY interrupt, and handler
>  - Memory objects for isolates are updated on a stack check, add
>    tracking for isolates that hit the stack check
>  - When enough memory is not reserved ahead of time, fail to grow
>  - Add tracking for externalized buffers in the MemoryTracker so
>    that the MemoryTracker will know when backing_stores can be freed.
>  - For shared buffer, do not always allocate a new buffer when
>    growing an externalized buffer
> 
> 
> Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
> Bug: v8:8564
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#60064}

TBR=binji@chromium.org,titzer@chromium.org,gdeepti@chromium.org,ahaas@chromium.org

Change-Id: I2ed0b59bcbb285b701172b401d606963261d375c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1506355Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60068}
      e15bb0b3
    • Deepti Gandluri's avatar
      [wasm] Lazy update instances on a shared Memory.Grow · 80f06d6f
      Deepti Gandluri authored 
       - Introduce a GROW_SHARED_MEMORY interrupt, and handler
 - Memory objects for isolates are updated on a stack check, add
   tracking for isolates that hit the stack check
 - When enough memory is not reserved ahead of time, fail to grow
 - Add tracking for externalized buffers in the MemoryTracker so
   that the MemoryTracker will know when backing_stores can be freed.
 - For shared buffer, do not always allocate a new buffer when
   growing an externalized buffer


Change-Id: I9cf1be19f2f165fa6ea4096869f7d6365304c8c4
Bug: v8:8564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1472430
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Reviewed-by: 's avatarBen Smith <binji@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#60064}
      80f06d6f
  31. 26 Dec, 2018 1 commit
  33. 18 Dec, 2018 1 commit
  35. 11 Dec, 2018 1 commit
  37. 29 Oct, 2018 1 commit
  39. 30 May, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] use interrupt for pause only as last resort · 6d87d957
      Alexey Kozyatinskiy authored 
      With this CL we use interrupt for pause in two cases:
- when we process Debugger.pause on interruption,
- when we would like to break as soon as possible after OOM.
In all other cases, e.g. for async step into we use break
on function call by calling StepIn debugger action.

In mentioned cases we should not actually use interrupt as well:
- Debugger.pause in this case scheduled using interrupt and we
  may just break right now without requesting another interrupt,
  unfortunately blink side is not ready,
- we should use more reliable way to break right after near OOM
  callback, otherwise we can get this callback, increase limit,
  request break on next interrupt, before interrupt get another
  huge memory allocation and crash.

There are couple advantages:
- we get much better break locations for async stepping
  (see inspector tests expectations),
- we can remove DEBUG_BREAK interruption
  (it should speedup blackboxing with async tasks, see
  removed todo in debug.cc for details)
- it is required preparation step for async step out,
  (see https://chromium-review.googlesource.com/c/v8/v8/+/1054618)

Bug: v8:7753
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iabd7627dbffa9a0eab1736064caf589d02591926
Reviewed-on: https://chromium-review.googlesource.com/1054155
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53439}
      6d87d957
  41. 04 May, 2018 1 commit
  43. 23 Apr, 2018 1 commit
    • Alexey Kozyatinskiy's avatar
      [runtime] implemented SafeForInterruptsScope · d3f6c647
      Alexey Kozyatinskiy authored 
      This CL introduced SafeForInterruptsScope. This scope overrides
outer PostponeInterruptsScopes:
- reschedule postponed interrupts if needed,
- allow requesting new interrupts.
As soon as scope removed interrupts are posponed if needed.

This scope will be:
- used to allow inspector to interrupt and terminate
  DebugeEvaluate::Local,
- exposed with new flag on Isolate to implement SafeForTerminationScope
  in blink.

R=yangguo@chromium.org

Bug: chromium:820640
Change-Id: I15befc10c2cee393d1e3be48cecb31ee14dae638
Reviewed-on: https://chromium-review.googlesource.com/1022969
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52743}
      d3f6c647
  45. 09 Apr, 2018 1 commit
  47. 26 Feb, 2018 1 commit
  49. 09 Jan, 2018 1 commit
  51. 04 Dec, 2017 1 commit
    • Caitlin Potter's avatar
      [builtins] implement RunMicrotasks pump as a code stub · 52ff3ae4
      Caitlin Potter authored 
      - Implement RunMicrotasks in CSA to prevent a potentially large number
  of jumps between C++ and JS code while consuming te queue. Appears to
  provide a ~60% speedup in microtask-heavy code, which from limited
  testing appears to scale linearly.

  The code-stub microtask pump bails out to the old C++ microtask pump
  if it encounters a CallHandlerInfo microtask, and remains in C++ for
  the remainder of the queue (returning to the JS/stub implementation
  after the bailed out queue is exhausted).

- Add a variation of JSEntryStub which enters the new RunMicrotasks code
  stub.

- Add a new RunMicrotasks helper to Execution, which uses the
  RunMicrotasks entry stub.

Bug: 
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
      52ff3ae4
  53. 01 Dec, 2017 1 commit
  55. 19 Jun, 2017 1 commit
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector (reland) · 24b7026d
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback
vector to store an optimization marker (optimize/in optimization queue)
rather than changing the JSFunction's code object. Then, adapt the
self-healing mechanism to also dispatch based on this optimization
marker. Similarly, replace SFI marking with optimization marker checks
in CompileLazy.

This allows JSFunctions to share optimization information (replacing
shared function marking) without leaking this information across native
contexts. Non I+TF functions (asm.js or --no-turbo) use a
CheckOptimizationMarker shim which generalises the old
CompileOptimized/InOptimizationQueue builtins and also checks the same
optimization marker as CompileLazy and InterpreterEntryTrampoline.

This is a reland of https://chromium-review.googlesource.com/c/509716

Change-Id: I02b790544596562373da4c9c9f6afde5fb3bcffe
Reviewed-on: https://chromium-review.googlesource.com/535460Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45997}
      24b7026d
  57. 13 Jun, 2017 2 commits
    • Leszek Swirski's avatar
      Revert "[compiler] Drive optimizations with feedback vector" · 58978da6
      Leszek Swirski authored 
      This reverts commit e39c9e02.

Reason for revert: Breaks https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20debug/builds/15561

Original change's description:
> [compiler] Drive optimizations with feedback vector
> 
> For interpreted functions, use the optimized code slot in the feedback vector
> to store an optimization marker (optimize/in optimization queue) rather than
> changing the JSFunction's code object. Then, adapt the self-healing mechanism
> to also dispatch based on this optimization marker. Similarly, replace SFI
> marking with optimization marker checks in CompileLazy.
> 
> This allows JSFunctions to share optimization information (replacing shared
> function marking) without leaking this information across native contexts. Non
> I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
> generalises the old CompileOptimized/InOptimizationQueue builtins and also
> checks the same optimization marker as CompileLazy and
> InterpreterEntryTrampoline.
> 
> Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
> Reviewed-on: https://chromium-review.googlesource.com/509716
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#45901}

TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,leszeks@chromium.org
No-Presubmit: true
No-Tree-Checks: true
No-Try: true

Change-Id: Ib6c2b4d90fc5f659a6dcaf3fd30321507ca9cb94
Reviewed-on: https://chromium-review.googlesource.com/532916Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45903}
      58978da6
    • Leszek Swirski's avatar
      [compiler] Drive optimizations with feedback vector · e39c9e02
      Leszek Swirski authored 
      For interpreted functions, use the optimized code slot in the feedback vector
to store an optimization marker (optimize/in optimization queue) rather than
changing the JSFunction's code object. Then, adapt the self-healing mechanism
to also dispatch based on this optimization marker. Similarly, replace SFI
marking with optimization marker checks in CompileLazy.

This allows JSFunctions to share optimization information (replacing shared
function marking) without leaking this information across native contexts. Non
I+TF functions (asm.js or --no-turbo) use a CheckOptimizationMarker shim which
generalises the old CompileOptimized/InOptimizationQueue builtins and also
checks the same optimization marker as CompileLazy and
InterpreterEntryTrampoline.

Change-Id: I6826bdde7ab9a919cdb6b69bc0ebc6174bcb91ae
Reviewed-on: https://chromium-review.googlesource.com/509716
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#45901}
      e39c9e02
  59. 30 May, 2017 1 commit
  61. 26 May, 2017 1 commit
  63. 08 Feb, 2017 1 commit
  65. 27 Jan, 2017 1 commit
  67. 23 Jan, 2017 1 commit
  69. 20 Jan, 2017 1 commit