- 11 Aug, 2021 1 commit
-
-
Samuel Groß authored
When this is enabled, v8 reserves a large region of virtual address space during initialization, at the start of which it will place its 4GB pointer compression cage. The remainder of the cage is used to store ArrayBuffer backing stores and WASM memory buffers. This will later allow referencing these buffers from inside V8 through offsets from the cage base rather than through raw pointers. Bug: chromium:1218005 Change-Id: I300094b07f64985217104b14c320cc019f8438af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#76234}
-
- 16 Jun, 2021 1 commit
-
-
John Xu authored
The Cobalt team uses base/wrappers.h to intercept some low level OS functions and recently we found strdup to be a blocker. Thankfully it only appeared once in V8. Change-Id: Ib20f399f94933b5d407c1e22e1df674420003ba2 Bug: v8:10927 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2963805 Auto-Submit: John Xu <johnx@google.com> Commit-Queue: John Xu <johnx@google.com> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75171}
-
- 10 Jun, 2021 1 commit
-
-
John Xu authored
For Cobalt's purpose in the past, we introduced base::Memcpy to intercept memcpy calls and replace it with SbMemoryCopy on Starboard/Cobalt. Recently Cobalt removed SbMemoryCopy because we found out that memcpy implementation is universal. To reduce the cost to maintain base::Memcpy, let us remove it and revert back to raw memcpy. Bug: v8:10927 Change-Id: I060f191f8f1aed8b78ffe4558a3743f3a2da008b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951462Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: John Xu <johnx@google.com> Cr-Commit-Position: refs/heads/master@{#75070}
-
- 08 Jun, 2021 1 commit
-
-
Ulan Degenbaev authored
Change-Id: I4a30e0f01e35eb0824f5abeec62d55d62970b59f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910781Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#75016}
-
- 27 Apr, 2021 1 commit
-
-
Nico Weber authored
Bug: v8:11699 Change-Id: I286ea7d3a6455528c66eee3f479455bfc49f190c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2852039 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#74232}
-
- 23 Apr, 2021 1 commit
-
-
Nico Weber authored
Bug: chromium:1196278 Change-Id: If80b1264f537e3828867831ac4d4dfc005a1ae8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2845243 Auto-Submit: Nico Weber <thakis@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74149}
-
- 08 Apr, 2021 1 commit
-
-
Sara Tang authored
This CL implements the equivalent of ETW in macos (called Signposts) Bug: v8:11043 Change-Id: Ifa72cfd17fca81b18e3e8b1003fd6ab72de3c986 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2807157 Commit-Queue: Sara Tang <sartang@microsoft.com> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73856}
-
- 01 Apr, 2021 1 commit
-
-
Sara Tang authored
Feedback from Microsoft partners indicates that it would be beneficial to enable ETW stack-walking events by default. This is difficult, because the --interpreted-frames-native-stack flag comes with a significant perf degradation. Ideally, we would turn this flag on dynamically, only when a ETW recorder is actively triggering the provider. Unfortunately, the flag in its current state cannot be enabled dynamically. In light of this, we have decided to only flip the build flag. Bug: v8:11043 Change-Id: Id883b9bcd635b41139450ab2d5c92511422525a3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2773792Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73784}
-
- 02 Mar, 2021 1 commit
-
-
Sara Tang authored
Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U This is the second (and hopefully final!) change list needed to integrate ETW into V8. In particular, we added stack-walking functionality for JIT-ted functions! Some notes on instrumentation: - The gist of getting stack-walking in ETW is we need to emit events with specific event IDs. These events get stitched into a pseudo-PDB that is recognizable by ETW. - Unfortunately, we cannot rely on the TraceLogging API from the first CL, as it does not support specifying event IDs. Instead, Bill Ticehurst wrote an API that peels back the TraceLogging API just enough so that we can specify event IDs. This API is the entirety of etw-metdata.h - We attach a CodeEventHandler that logs a stack-walking event whenever code movement is triggered. Bug: v8:11043 Change-Id: I1bf57c985b7375f045089027855b1c03878abb78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616221Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73145}
-
- 25 Feb, 2021 1 commit
-
-
Hannes Payer authored
Change-Id: Ib54d5abad3e67f74d1930af135778e1f201ba28f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2712964 Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/master@{#73050}
-
- 05 Jan, 2021 1 commit
-
-
Sara Tang authored
Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U A lot has changed since the last patchset! I recommend revisiting this design doc and reading the parts in green. I explain the roadmap for what changes to expect from ETW instrumentation as well as the instrumentation of this particular CL. I'll do my best to answer any further questions anyone has about my particular instrumentation or ETW in general :) --- This is the first of a series of changelists to round out ETW instrumentation for V8. This changelist represents the most minimal change needed to instrument ETW in V8. In particular, it: - defines and registers the ETW provider, - interacts minimally with the rest of V8, by hooking into the existing TracingController::AddTraceEvent function, - is designed with a platform-agnostic layer, so that event tracers for other platforms can be instrumented in teh future. Some notes on instrumentation (aka I copied stuff from the design doc): We make heavy use of the TraceLogging API to log events. It differs from previous methods of emitting ETW events in that it doesn<E2><80><99>t require the overhead of a separate manifest file to keep track of metadata; rather, events using this API are self-descriptive. Here are the five major steps to instrument the TraceLogging API: - Forward declare the provider (from provider-win.h) - Define the provider in a .cc file (from provider-win.cc) - Register the provider (called from v8.cc). - Write events (called from libplatform/tracing-controller.cc) - Unregister the provider (called from v8.cc) At the base, we have an abstract provider class that encapsulates the functionality of an event provider. These are things like registering and unregistering the provider, and the actual event-logging. The provider class is split into provider-win and provider-mac (currently not instantiated) classes, with OS-dependent implementations of the above functions. In particular, the TraceLogging API is used only in provider-win. It is here that we forward declare and define the provider, as well as write ETW events. Finally, there is a v8-provider class that serves as a top-level API and is exposed to the rest of V8. It acts as a wrapper for the platform-specific providers. The .wprp file is needed so that Windows Performance Recorder knows how to capture our events. Some considerations: - Is TracingController::AddTraceEvent the best place from which to write my events? - Is src/libplatform/tracing the best place to put my instrumentation? - Right now, I fail the preupload because of this, which tells me my files are probably not in the best location: You added one or more #includes that violate checkdeps rules. src\init\v8.cc Illegal include: "src/libplatform/tracing/v8-provider.h" Because of "-src/libplatform" from src's include_rules. Change-Id: Id53e4a034c9e526524a17000da0a647a95d93edf Bug: v8:11043 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2233407Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71918}
-
- 10 Dec, 2020 1 commit
-
-
Etienne Pierre-doray authored
Follow up on https://chromium-review.googlesource.com/c/v8/v8/+/2510969 Now that gin implements the new version: https://chromium-review.googlesource.com/c/chromium/src/+/2566052 These can be deprecated. Change-Id: Ie1e5448655e40eb3c11089f59510f269a9873e66 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566430Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#71700}
-
- 08 Dec, 2020 1 commit
-
-
Etienne Pierre-doray authored
This is a reland of 064ee3c8 Issue 1: WasmEngine UAF when CompilationState is destroyed asynchronously Fix: Include https://chromium-review.googlesource.com/c/v8/v8/+/2565508 in this CL. Use OperationBarrier to keep WasmEngine alive. Issue 2: In gin, JobTask lifetime is not extended beyond JobHandle, thus making CancelAndDetach unusable. This is fixed in chromium here: https://chromium-review.googlesource.com/c/chromium/src/+/2566724 Original change's description: > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob." > > Reason for revert: Data race: > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121 > > It was assume that MockPlatform runs everything on 1 thread. However, > MockPlatform::PostJob previously would schedule the job through > TestPlatform, which eventually posts concurrent tasks, thus causing > data race. > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform > ensures the jobs also run sequentially. > > Additional change: > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure > it's called in sequence with ScheduleCompileJobForNewUnits > > Original CL description: > To avoid keeping around a list of job handles, CancelAndDetach() is > used in CancelCompilation. Dependency on WasmEngine is handled by a > barrier that waits on all jobs to finish. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Original-Commit-Position: refs/heads/master@{#71074} > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71459} TBR=ulan@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Change-Id: I6175092c97fea0d5f63a97af232e2d54cccea535 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569360 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71662}
-
- 01 Dec, 2020 2 commits
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I0b819aba03d720780142bcc937e2f148d39f9be9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2567537 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71520}
-
Etienne Pierre-Doray authored
This reverts commit 064ee3c8. Reason for revert: Causing blink_web_tests to fail on builder "WebKit Linux MSAN" https://bugs.chromium.org/p/chromium/issues/detail?id=1153968 Original change's description: > Reland "[wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob." > > Reason for revert: Data race: > https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121 > > It was assume that MockPlatform runs everything on 1 thread. However, > MockPlatform::PostJob previously would schedule the job through > TestPlatform, which eventually posts concurrent tasks, thus causing > data race. > Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform > ensures the jobs also run sequentially. > > Additional change: > - CancelAndDetach is now called in ~CompilationStateImpl() to make sure > it's called in sequence with ScheduleCompileJobForNewUnits > > Original CL description: > To avoid keeping around a list of job handles, CancelAndDetach() is > used in CancelCompilation. Dependency on WasmEngine is handled by a > barrier that waits on all jobs to finish. > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Original-Commit-Position: refs/heads/master@{#71074} > Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137 > Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71459} TBR=ulan@chromium.org,jkummerow@chromium.org,ahaas@chromium.org,clemensb@chromium.org,etiennep@chromium.org Bug: chromium:1153968, v8:11209, v8:11210, v8:11212 # Not skipping CQ checks because original CL landed > 1 day ago. Change-Id: I2c8406bea81ee7cf6c5726c2fec50fffdce09611 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2566446Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71519}
-
- 27 Nov, 2020 1 commit
-
-
Etienne Pierre-doray authored
Reason for revert: Data race: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121 It was assume that MockPlatform runs everything on 1 thread. However, MockPlatform::PostJob previously would schedule the job through TestPlatform, which eventually posts concurrent tasks, thus causing data race. Fix: Manually calling NewDefaultJobHandle and passing the MockPlatform ensures the jobs also run sequentially. Additional change: - CancelAndDetach is now called in ~CompilationStateImpl() to make sure it's called in sequence with ScheduleCompileJobForNewUnits Original CL description: To avoid keeping around a list of job handles, CancelAndDetach() is used in CancelCompilation. Dependency on WasmEngine is handled by a barrier that waits on all jobs to finish. Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#71074} Change-Id: Ie9556f7f96f6fb9a61ada0e5cbd58d4fb4a0f571 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2559137 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71459}
-
- 26 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Scopes in V8 are used to guarantee one or more properties during its lifetimes. If a scope is not named e.g MyClassScope(args) instead of MyClassScope scope(args) it will get created and automatically destroyed and therefore, being useless as a scope. This CL would produce a compiling warning when that happens to ward off this developer error. Follow-up to ccrev.com/2552415 in which it was introduced and implemented for Guard classes. Change-Id: Ifa0fb89cc3d9bdcdee0fd8150a2618af5ef45cbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2555001 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71425}
-
- 17 Nov, 2020 1 commit
-
-
John Xu authored
Bug: v8:10927 Change-Id: Icbdc0d7329ddd466e7d67a954246a35795b4dece Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507310 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71220}
-
- 13 Nov, 2020 1 commit
-
-
Ulan Degenbaev authored
The new platform can be used in combination with --single-threaded. It disables background threads and thus avoids waiting on mutexes and condition variables completely, which is useful for V8 embedders that fork the V8 process after initialization. As a bonus the new platform allows use to test --single-threaded and has already uncovered an existing bug in parallel pointer updating code. Change-Id: I3446fa027d2a077641cdaac0cd08062a1acae176 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2416501 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#71187}
-
- 10 Nov, 2020 2 commits
-
-
Clemens Backes authored
This reverts commit a74f9eb6. Reason for revert: Data race: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34121 Original change's description: > [wasm]: Use CancelAndDetach and barrier on BackgroundCompileJob. > > To avoid keeping around a list of job handles, CancelAndDetach() is > used in CancelCompilation. Dependency on WasmEngine is handled by a > barrier that waits on all jobs to finish. > > > Change-Id: I685a1737354b2fb3d1f4b98580926a93da38be5b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71074} TBR=ulan@chromium.org,jkummerow@chromium.org,clemensb@chromium.org,etiennep@chromium.org Change-Id: I9288abd03b572059ac5278d2e5b84bd418b4d69d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529132Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#71078}
-
Etienne Pierre-doray authored
To avoid keeping around a list of job handles, CancelAndDetach() is used in CancelCompilation. Dependency on WasmEngine is handled by a barrier that waits on all jobs to finish. Change-Id: I685a1737354b2fb3d1f4b98580926a93da38be5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2498659 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#71074}
-
- 30 Oct, 2020 1 commit
-
-
Etienne Pierre-doray authored
IsCompleted is backwards. For a more consistent api, the function is renamed IsActive and logic is flipped. Following up on https://chromium-review.googlesource.com/c/v8/v8/+/2461840 The intend is to make the distinction between IsActive and IsValid obvious. Change-Id: Iaf00b9f6ffa8f1efe93ae29f09899737ef20f04d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2510969Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#70901}
-
- 20 Oct, 2020 1 commit
-
-
Edward Lesmes authored
Generate DIR_METADATA files and remove metadata from OWNERS files for v8. R=jkummerow@chromium.org, ochang@chromium.org, yangguo@chromium.org Bug: chromium:1113033 Change-Id: I82cbb62e438d82dbbc408e87120af39fa9da0afa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476680Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Edward Lesmes <ehmaldonado@chromium.org> Auto-Submit: Edward Lesmes <ehmaldonado@chromium.org> Cr-Commit-Position: refs/heads/master@{#70669}
-
- 19 Oct, 2020 1 commit
-
-
Etienne Pierre-doray authored
IsRunning is the v8 equivalent of operator bool, but is confusing with IsCompleted. IsValid (to match base:: operator bool) should be more clear. Change-Id: I2529bea21c7cb7613bd5057c66715fb5ea450396 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461840Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#70625}
-
- 07 Oct, 2020 1 commit
-
-
Omer Katz authored
This CL aligns the library implementation with the blink implementation: (*) Concurrent marking increases job priority if no concurrent progress is made in the last 50% of the expected marking duration. (*) Concurrent sweeping increases job priority when calling FinishIfRunning (the library equivalent of blink's CompleteSweep). Bug: chromium:1056170 Change-Id: Ice275cb90a7dd76bf4125f4338d9d80e5f576c58 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431572 Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#70375}
-
- 06 Oct, 2020 1 commit
-
-
Etienne Pierre-doray authored
This is useful for wasm instead of keeping around a list of handles. Change-Id: I4ef970ba191a66303c577bbe8e6ab1327aad2e24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2451209Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#70353}
-
- 29 Sep, 2020 1 commit
-
-
Etienne Pierre-doray authored
Delegate kept task id around for longer than the worker is considered active, thus breaking the task_id < num_worker garantee. The fix is to adjust the delegate lifetime. Change-Id: I9aabb1286d507c09bfe9be4fd4f810f232d6e6b9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2437005 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#70207}
-
- 17 Sep, 2020 1 commit
-
-
Etienne Pierre-doray authored
To let the user do special handling on the main thread e.g. Scavenging uses different tracing categories for background/foreground threads. Change-Id: I6c9187fd6201b5b81cd83727727fda49fcf7ff68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2405797Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#69978}
-
- 10 Sep, 2020 1 commit
-
-
Etienne Pierre-doray authored
This reflects the change made in chrome: https://chromium-review.googlesource.com/c/chromium/src/+/2387554 I somehow thoughts that DefaultJob didn't need the fence, but TSAN detected the same kind of failures after 9e8c54f8 started using AcquireTaskId. Drive-by: move delegate outside the loop in Join() to avoid releasing the task_id many times. Change-Id: I2ab6bf1bd3eeb7a66e39f20a7e0aa61a9c1ebc44 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2401964Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Cr-Commit-Position: refs/heads/master@{#69818}
-
- 26 Aug, 2020 1 commit
-
-
Clemens Backes authored
The {priority_} field is being updated in {DefaultJobState::Join}, under {mutex_}. In other places though, it is read unprotected (without holding the mutex), leading to data races. This CL fixes that by reading the field while holding the mutex and using the read priority after releasing the mutex. Note that the {priority_} field is documented to be protected by {mutex_}, so the unprotected read was a bug. R=ulan@chromium.org CC=etiennep@chromium.org Bug: v8:10822 Change-Id: I80079f3cb6689e26116ffeb33755c6938c4a2cf1 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2377685Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69571}
-
- 25 Aug, 2020 1 commit
-
-
Etienne Pierre-doray authored
- JobHandle::IsCompleted() - JobDelegate::GetTaskId() - worker_count passed as argument to GetMaxConcurrency(). Jobs implementation must call the new GetMaxConcurrency(), but Jobs users aren't migrated yet. Bug: chromium:1114823 Change-Id: I0f4295ccaf9eba866dd771f30e2e49aa3eae9551 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2352484 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69553}
-
- 20 Aug, 2020 1 commit
-
-
Ulan Degenbaev authored
Change-Id: I328dde4ef8265fa15e2dfc7ac689e175465edebd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2366700Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69503}
-
- 06 Aug, 2020 1 commit
-
-
Clemens Backes authored
Wasm recently switched from spawning a number of background tasks for compilation to just using a single job (via the pretty new {Platform::PostJob} API). This caused major regressions in several benchmarks running in d8, because the {DefaultPlatform} is only using half of the available worker threads for executing jobs with "user visible" priority. This CL changes this to use all available worker threads for "user blocking" or "user visible" jobs, and two threads for "best effort" jobs. The limit of two threads for best effort is identical to what chromium does with best effort *tasks*. For user blocking and user visible, chromium does not impose any limit, so we also remove the limitation to half of the threads from d8. Drive-by: Use {NewDefaultJobHandle} for constructing {DefaultJobHandle}. R=mlippautz@chromium.org CC=ahaas@chromium.org, gab@chromium.org, etiennep@chromium.org Bug: chromium:1113234, chromium:1101340 Change-Id: I9280e649a1cf3832c562ff7251e8bda0103af111 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339481Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Auto-Submit: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69265}
-
- 20 Jul, 2020 1 commit
-
-
Clemens Backes authored
This will allow embedders to actually instantiate the {DefaultJobHandle} as suggested in the comment. Node currently implements {PostJob()} by just returning a nullptr. After this change, it can use the new {NewDefaultJobHandle} function and we can actually start using this API in v8. R=adamk@chromium.org Bug: v8:10723 Change-Id: I4b31a640d0edc7e7207d1df95e683465dfaaaeff Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304812Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#68934}
-
- 25 Jun, 2020 1 commit
-
-
Marja Hölttä authored
Design doc: https://docs.google.com/document/d/1BU-Zyco8YPP2Ra0Y3eVZ_BllzpUkJaJhmVmmnGD44Yc/edit#heading=h.mmdxlkic7kqd Bug: v8:10239 Change-Id: Ie1b953c8242e32a0447440aaae7c2ed377c97511 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2259933 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#68540}
-
- 04 Jun, 2020 1 commit
-
-
Ng Zhi An authored
Making them private was a way to hide the functions, we can explicitly delete them, which give a better compilation error message as well. Also see: https://stackoverflow.com/q/55205874 Bug: v8:10488 Change-Id: I24f70dc1f6fb227185b6f8ecb30a81e218dd2a50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2223232Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#68186}
-
- 08 May, 2020 1 commit
-
-
Daniel Bevenius authored
It looks like the usages of these were removed in Commit 8a1bafaf ("Reland "[platform] Implement TaskRunners in the DefaultPlatform"). Change-Id: I61865548020b6dc0ee7d658080ad148c7ffd6e42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2187500Reviewed-by:
Andreas Haas <ahaas@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#67680}
-
- 06 May, 2020 1 commit
-
-
Clemens Backes authored
The number of worker threads in the default platform is currently capped at 8. At runtime, it's also capped by the number of actual cores available. Since d8 is often used for benchmarking (both internally and externally), this CL slightly increases the maximum to 16. At least wasm compilation is known to scale beyond 8 threads. If this increase does not cause any problems on bots, we might increase further in the future. R=mlippautz@chromium.org Change-Id: I04e138c51d7dc26c38b9384c8ea67a883c976050 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182454 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67586}
-
- 05 May, 2020 1 commit
-
-
Clemens Backes authored
This function is always called right after creating the DefaultPlatform, hence merge it into the constructor. R=mlippautz@chromium.org Change-Id: I4afb14c83740224056157665db6b854c659da0c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182635Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#67573}
-
- 24 Apr, 2020 1 commit
-
-
Etienne Pierre-doray authored
The impl works by posting up to NumberOfWorkerThreads() tasks with CallOnWorkerThread(). Change-Id: I188ac57c9e5d6e3befdcc6f945fbf337dabe1d1d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2130886 Commit-Queue: Etienne Pierre-Doray <etiennep@chromium.org> Reviewed-by:
Gabriel Charette <gab@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#67368}
-