- 13 Jan, 2022 1 commit
-
-
Lei Zhang authored
Use grep to check for obviously unneeded includes. e.g. headers that include <vector> but does not contain "std::vector". Change-Id: I43a9e9f01e072fd495918d28ca4cdad5cfa0294c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3354400Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/main@{#78613}
-
- 10 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Some bad rebasing meant that we were still deleting on the main thread. As an additional simplification, remove the specific deletion queue mutex, and just use the compiler dispatcher mutex for the deletion queue -- this avoids risks of deadlock when both are held. Change-Id: Ifa4ead6ee3fd814d7f013dd14a5617456afc9f7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3328785 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78335}
-
- 08 Dec, 2021 3 commits
-
-
Leszek Swirski authored
Deleting / deallocating Jobs, along with everything they own (e.g. PersistentHandles), can take a long time, especially if the allocator isn't too friendly to deallocating on a different thread than where the allocation happened. Instead, enqueue Jobs for deletion as part of background processing, with the hope that they end up being deallocated on the same thread as they were allocated, and at the very least taking the deallocation time off the main thread. The deletion queue is processed after the pending background jobs are all processed, and counts as a single "background job" as far as parallelism is concerned. Bug: chromium:1275157 Change-Id: Ie7c3f725f7e510b4325e7590e60477338c478388 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314835Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78307}
-
Leszek Swirski authored
Reduce the enqueuing cost of compiler-dispatcher jobs by getting rid of the sets and hashmaps, and instead: 1. Turning the pending job set into a queue, and 2. Making the SharedFunctionInfo's UncompiledData hold a pointer to the LazyCompilerDispatcher::Job, instead of maintaining an IdentityMap from one to the other. To avoid bloating all UncompiledData, this adds two new UncompiledData subclasses, making it four subclasses total, for with/without Preparse data and with/without a Job pointer. "should_parallel_compile" FunctionLiterals get allocated an UncompiledData with a job pointer by default, otherwise enqueueing a SFI without a job pointer triggers a reallocation of the UncompiledData to add a job pointer. Since there is no longer a set of all Jobs (aside from one for debug-only), we need to be careful to manually clear the Job pointer from the UncompiledData whenever we finish a Job (whether successfully or by aborting) and we have to make sure that we implicitly can reach all Jobs via the pending/finalizable lists, or the set of currently running jobs. Change-Id: I3aae78e6dfbdc74f5f7c1411de398433907b2705 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314833Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78302}
-
Leszek Swirski authored
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo, which stores a couple of pointers and most importantly the Zone and AstValueFactory of the parse. This allows the Zone and AstValueFactory to be reused across multiple parses, rather than re-initialising per-Parse. With this, we can amend the LazyCompileDispatcher to initialise one LocalIsolate, Zone and AstValueFactory per background thread loop, rather than one per compile task, which allows us to reduce per-task costs and re-use the AstValueFactory's string table and previous String internalizations. Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78289}
-
- 03 Dec, 2021 2 commits
-
-
Leszek Swirski authored
Rather than creating a ParseInfo when creating a BackgroundCompileTask (and passing ownership across to the BG thread which deallocates it), create one when running it. This allows the ParseInfo Zone to be both allocated and deallocated on the same thread, which will improve its allocator friendliness. As a side-effect, we now use the on-heap PreparseData from the SharedFunctionInfo, rather than cloning the in-Zone PreparseData. This means that we don't have to copy the PreparseData across Zones, but we do need to Unpark the LocalHeap when accessing preparse data. Change-Id: I16d976c1ad54c1090180f2936f40a23a6dbb5904 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312483Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78228}
-
Leszek Swirski authored
Finalize other finalizable jobs in FinishNow, up to a time deadline. This deadline is set to 1ms for now, because that seems like short enough to not get in the way of user interaction but long enough to be worth doing here rather than doing another runtime call for the subsequent funtions. Change-Id: I79f0780e9318e97efee03d2d25701009ca7069d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3310801 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78227}
-
- 01 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Add suppose for compiling non-eager, non-top-level inner functions in parallel, using the compiler dispatcher. This behaviour can be enabled with --parallel-compile-tasks-for-lazy. There are a couple of consequences: * To support this we need support for off-thread ScopeInfo deserialization, so this adds that too. * The previous --parallel-compile-tasks flag is renamed to the more descriptive --parallel-compile-tasks-for-eager-toplevel. * Both parallel-compile-tasks flags are moved onto UnoptimizedCompileFlags so that they can be enabled/disabled on a per-compile basis (e.g. enabled for streaming, disabled for re-parsing). * asm.js compilations can now happen without an active Context (in the compiler dispatcher's idle finalization) so we can't get a ContextId for metric reporting; we'd need to somehow fix this if we wanted asm.js UKM but for now it's probably fine. * Took the opportunity to clean up some of the "can preparse" logic in the parser. Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/main@{#78183}
-
- 15 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Posting compile tasks from the parser has several issues: 1. We don't know how many functions there will be total, so we can't yet allocate shared_function_infos array on the Script 2. Without this array, inner function compiles can't look up their own inner functions during bytecode finalization, so we can't run that finalization before script parse completes 3. Scope analysis can't have run yet, so we can only post top-level function tasks and if we allocate SharedFunctionInfos early they are forced into a bit of a limbo state without an outer ScopeInfo. Instead, we can post compile tasks during bytecode generation. Then, the script parse is guaranteed to have completed, so we'll have a shared_function_infos array and we will have allocated ScopeInfos already. This also opens the door for posting tasks for compiling more inner functions than just top-level, as well as generating better code for functions/methods that reference same-script top-level let/const/class. Bug: chromium:1267680 Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77894}
-
- 12 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Due to streaming, the SFI enqueueing can happen concurrently with with main-thread finalising, so we need to add locks around accesses to the SFI->Job map. Bug: v8:12370 Change-Id: I60281a954ef10f7fcde559b9529077a6b9a82c31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277874 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77869}
-
- 05 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Remove FunctionLiterals and ParseInfo from the LazyCompileDispatcher API, passing instead the SharedFunctionInfo, a character stream, and optionally some preparse data. In the future, this should allow us to pass arbitrary uncompiled SharedFunctionInfos into the LazyCompileDispatcher. Change-Id: Iff90408f3b259c7f5df0e74687d052e75959fa48 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262131Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77723}
-
- 04 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Remove the concept of JobId from LazyCompileDispatcher, and make SFIs the canonical id for these jobs. This has several consequences: * We no longer split enqueing a job and registering a SFI with that job. We did this previously because we could not allocate SFIs in the Parser -- now with LocalHeap we can, so we do. * We remove the separate Job vector, and make the SFI IdentityMap hold pointers to Jobs directly. This requires a small amount of extra care to deallocate Jobs when removing them from the map, but it means not having to allocate new global handles for jobs. * The SFI is passed into the BackgroundCompileTask instead of the script, so our task finalization doesn't need the SFI anymore. * We no longer need to iterate ParallelTasks after compiling (to register SFIs), so we can get rid of ParallelTasks entirely and access the dispatcher directly from the parser. There are a few drive-bys since we're touching this code: * Jobs are move to have a "state" variable rather than a collection of bools, for stricter DCHECKing. * There's no longer a set of "currently running" jobs, since this was only used to check if a job is running, we can instead inspect the job's state directly. * s/LazyCompilerDispatcher/LazyCompileDispatcher/g Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77712}
-
- 03 Nov, 2021 1 commit
-
-
Leszek Swirski authored
This is a reland of 35a6eeec Reland fixes: * Add a SharedFunctionInfo::CopyFrom to encapsulate updating the SFI from the placeholder. This now includes copying scope_info (which wasn't included in the original CL and caused some of the issues) * Make sure that LocalHandleScope is initialised only inside of UnparkedScope (fixed TSAN issues) * Clean-up: Don't add `script_` to ParseInfo, but instead pass it separately to Parser. Eventually we'd ideally get rid of ParseInfo entirely (splitting it into input and output) so let's not add more fields to it. Reverts changing CreateScript to InitializeScript. Original change's description: > [off-thread] Allow off-thread top-level IIFE finalization > > Allow off-thread finalization for parallel compile tasks (i.e. for top- > level IIFEs). > > This allows us to merge the code paths in BackgroundCompileTask, and > re-enable the compiler dispatcher tests under the off-thread > finalization flag. Indeed, we can simplify further and get rid of that > flag entirely (it has been on-by-default for several releases now). > > Change-Id: I54f361997d651667fa813ec09790a6aab4d26774 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226780 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77615} Change-Id: If1a5b14900aa6753561e34e972a293be0be9a07d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3256692 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77676}
-
- 29 Oct, 2021 1 commit
-
-
Leszek Swirski authored
Port the CompilerDispatcher to use the Jobs API, instead of its own hand-rolled worker management. This required some re-thinking of how testing is handled, since the tests want to be able to a) Defer calls to PostTask/Job, to actuall post the jobs later. This was easy enough with PostTask, since we could simply store the task in a list and no-op, but PostJob has to return a JobHandle. The tests now have a DelayedJobHandleWrapper, which defers all method calls on itself, and because of all the unique_ptrs, there's also now a SharedJobHandleWrapper. b) Wait until tasks/jobs complete. Returning from a Task meant that the task had completed, but this isn't necessarily the case with JobTasks; e.g. a job might be asked to yield. This patch hacks around this by Posting and Joining a non-owning copy of the requested JobTask, and then re-posting it once Join returns. Change-Id: If867b4122af52758ffabcfb78a6701f0f95d896d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563664 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77618}
-
- 06 Aug, 2021 1 commit
-
-
Victor Gomes authored
We would like to use the name CompilerDispatcher for dispatcher base class to be used by Sparkplug and OptimizingCompileDispatcher. Bug: v8:12054 Change-Id: Id69955101c1f46fc2f79b6f77b05c92ed8a31edb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3077150 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76136}
-
- 03 Dec, 2020 1 commit
-
-
Zhi An Ng authored
Bug: v8:11074 Change-Id: I50476740e2e6c78aff6db859db1db86f25ce897b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2569561 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#71594}
-
- 06 Aug, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Now that we are using PersistentHandles, we don't need it anymore. Bug: v8:7790 Change-Id: Id0b9d555191c00fb08dc2bb9099746076c5ad1b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332161 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69278}
-
- 23 Apr, 2020 1 commit
-
-
Leszek Swirski authored
Move the persistent compilation state and Isolate inputs (such as the allocator, shared AST constants, hash seed, logger, etc.) which survives across both parse and compile, out of ParseInfo and into a new UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState for per-thread state such as stack limit and RCS. In particular, this new state survives the ParseInfo being destructed, which means it is available after off-thread finalization. This allows a followup to access the PendingCompilationErrorHandler after finalization and report errors on merge. Bug: v8:10314 Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#67329}
-
- 27 May, 2019 1 commit
-
-
Clemens Hammacher authored
This replaces all typedefs that define types and not functions by the equivalent "using" declaration. This was done mostly automatically using this command: ag -l '\btypedef\b' src test | xargs -L1 \ perl -i -p0e 's/typedef ([^*;{}]+) (\w+);/using \2 = \1;/sg' Patchset 2 then adds some manual changes for typedefs for pointer types, where the regular expression did not match. R=mstarzinger@chromium.org TBR=yangguo@chromium.org, jarin@chromium.org Bug: v8:9183 Change-Id: I6f6ee28d1793b7ac34a58f980b94babc21874b78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631409 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61849}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 2 commits
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
Yang Guo authored
Bug: v8:9247 Change-Id: I0023200c54fa6499ae4e2cf5e4c89407cc35f187 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624218Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61762}
-
- 28 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Bug: v8:3770 Change-Id: If405611d359d29ae1958beebd9202e068434a621 Reviewed-on: https://chromium-review.googlesource.com/c/1350286 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#57918}
-
- 18 Oct, 2018 1 commit
-
-
Ross McIlroy authored
Make sure we wait for the worker thread to finish compilation before removing aborted jobs. BUG=v8:8317,v8:8041 Change-Id: I42f30c4d430b7787ea5e724bdfda6460e5461233 Reviewed-on: https://chromium-review.googlesource.com/c/1288812Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56787}
-
- 15 Oct, 2018 1 commit
-
-
Ross McIlroy authored
Some jobs might need to be aborted, e.g., if a function is a default parameter in an arrow function it will be re-scoped and won't have a SFI to register. Adds support to abort jobs without having to block if the job is currently running on the background thread. BUG=v8:8041 Change-Id: I9149740401cbaaa31c21be9d79d4e3f5c450bfcf Reviewed-on: https://chromium-review.googlesource.com/c/1278497 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56637}
-
- 12 Oct, 2018 3 commits
-
-
Clemens Hammacher authored
LockGuard is mostly used with Mutex. Since both are defined outside the internal namespace, we often have to write {base::LockGuard<base::Mutex>}. This CL shortens this to {base::MutexGuard} across the code base R=mlippautz@chromium.org Bug: v8:8238 Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel Change-Id: I020d5933b73aafb98c4b72e3bb2dfd07c979ba73 Reviewed-on: https://chromium-review.googlesource.com/c/1278796Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#56612}
-
Ross McIlroy authored
The memory pressure notification logic wasn't correct and given the current users of the compiler dispatcher aren't posting speculative tasks, it isn't particularly useful. After removing this, the abort logic can also be simplified significantly by removing the non-blocking abort logic. BUG=v8:8041 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I584533b58fb717fdca46cc620822914d6bdb28b8 Reviewed-on: https://chromium-review.googlesource.com/c/1278495Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56609}
-
Ross McIlroy authored
There was a small race where an idle task could be posted after the compiler dispatcher had aborted and the CancellableTaskRunner had been cancelled. This was causing flakyness on the bots. This fixes this by moving the idle task posting into the same lock block as the notification to the main thread that the background task has completed. BUG=v8:8041 Change-Id: I43ca4cea807bfdfeb13f6d1c4a67a4d8a4f6291f Reviewed-on: https://chromium-review.googlesource.com/c/1278494Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#56607}
-
- 09 Oct, 2018 1 commit
-
-
Ross McIlroy authored
Simplify the logic in the CompilerDispatcher to use BackgroundCompileTasks directly, rather than having a (now unecessary) CompilerDispatcherJob abstraction. In the process, the CompilerDispatcherTracer is removed, and the idle task logic is simplified finalize already compiled jobs until the idle task deadline. BUG=v8:8238, v8:8041 Change-Id: I1ea2366f959b6951de222d62fde80725b3cc70ff Reviewed-on: https://chromium-review.googlesource.com/c/1260123 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56473}
-
- 04 Oct, 2018 1 commit
-
-
Andreas Haas authored
We want to replace all uses of CallOnForegroundThread eventually by the new TaskRunner API so that we can eventually deprecate the old API and remove it. R=leszeks@chromium.org Bug: v8:8238 Change-Id: I6a1e55fe431225ffe4c77cd3387f3b060eb43edf Reviewed-on: https://chromium-review.googlesource.com/c/1256866Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#56375}
-
- 25 Sep, 2018 1 commit
-
-
Ross McIlroy authored
This CL makes UnoptimizedCompilationJob a simple proxy for BackgroundCompilerTask. A follow-up CL will remove UnoptimizedCompilationJob entirely and have CompilerDispatcher deal directly with BackgroundCompilerTasks BUG=v8:8041, v8:8015 Change-Id: Ia53d05c015c4ca2ee32a4d1c5d0c65edb3caeda8 Reviewed-on: https://chromium-review.googlesource.com/1236257 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56212}
-
- 20 Sep, 2018 1 commit
-
-
Ross McIlroy authored
Refactors the CompilerDispatcher to be able to enqueue eager inner functions for off-thread compilation during top-level compilation of a script. Unoptimized compile jobs are simplified to only have two phases - compile and finalization. Only finalization requires heap access (and therefore needs to be run on the main thread). The change also introduces a requirement to register a SFI with a given compile job after that job is posted, this is due to the fact that an SFI won't necessarily exist at the point the job is posted, but is created later when top-level compile is being finalized. Logic in the compile dispatcher is update to deal with the fact that a job may not be able to progress if it doesn't yet have an associated SFI registered with it. BUG=v8:8041 Change-Id: I66cccd626136738304a7cab0e501fc65cf342514 Reviewed-on: https://chromium-review.googlesource.com/1215782 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#56088}
-
- 26 Mar, 2018 1 commit
-
-
Gabriel Charette authored
This is done now while embedders have yet to adapt to the new API before it becomes hard to migrate. Also renamed variable/methods to use "worker threads" rather than "background" nomenclature. Extracted from https://chromium-review.googlesource.com/c/v8/v8/+/978443/7 while resolving the more contentious bits around using task runners. TBR=rmcilroy@chromium.org Bug: chromium:817421 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ie3ddf15a708e829c0f718d89bebf3e96d1990c16 Reviewed-on: https://chromium-review.googlesource.com/980953 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: Gabriel Charette <gab@chromium.org> Cr-Commit-Position: refs/heads/master@{#52231}
-
- 01 Mar, 2018 1 commit
-
-
Gabriel Charette authored
Follow-up to https://chromium-review.googlesource.com/c/v8/v8/+/941442. "background" refers to a priority and is inappropriate to refer to worker threads as many tasks posted to worker threads by v8 are in fact high priority. Also took advantage of this rename to make NumberOfWorkerThreads() return an int instead of size_t. While it is never negative, int is simpler and Google C++ style guide states to avoid unsigned integers in such cases (ref. "On Unsigned Integers" @ https://google.github.io/styleguide/cppguide.html#Integer_Types). The Chromium embedder for that call provided an int which was converted to size_t for this override and most often casted back down to int on the v8 side, adding churn, and readability overhead. R=ahaas@chromium.org Bug: v8:7310 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: Ib5280df73d2846b111d985be65a10b049995ea6a Reviewed-on: https://chromium-review.googlesource.com/941944 Commit-Queue: Gabriel Charette <gab@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#51662}
-
- 20 Feb, 2018 1 commit
-
-
Sigurd Schneider authored
This ensures that breaking on inlined builtins works, even when compiling concurrently. This CL also introduces the member Isolate::AbortConcurrentOptimization. R=sigurds@chromium.org Bug: v8:178 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Change-Id: Ie6cbb48ebde18036888af2dd715862e7a14ddf9d Reviewed-on: https://chromium-review.googlesource.com/912468 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#51384}
-
- 18 Aug, 2017 1 commit
-
-
Ross McIlroy authored
Parse tasks are not currently used, and will need to be changed significantly for background compilation, so we remove them for now. BUG=v8:6093,v8:5203 Change-Id: I44559a94ecca85668f0117629d35aaa5f4075745 Reviewed-on: https://chromium-review.googlesource.com/617140 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#47446}
-
- 27 Jul, 2017 4 commits
-
-
Ross McIlroy authored
The approach to creating compiler dispatcher jobs for inner functions after they had been parsed didn't provide the startup benifits we hoped for due to the need to hold onto the whole zone memory AST while waiting for the jobs to complete. This CL removes the ability to create these compilation jobs (which was never enabled by default anyway). Going forward we will potentially use the parser task approach to parse+compile inner functions in their own job. BUG=v8:5203 Change-Id: I63134746aa23b4aa6e3bfa17c539954890fd9b0f Reviewed-on: https://chromium-review.googlesource.com/590007Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#46948}
-
Leszek Swirski authored
Reland of https://chromium-review.googlesource.com/c/558290/ Makes compiler dispatcher jobs an abstract interface, with unoptimized compile jobs as an implementation of this interface. Bug: v8:6537 Change-Id: Ia85781f72c7aaca497896ca4efa91ada97e43b1c Reviewed-on: https://chromium-review.googlesource.com/589154 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#46940}
-
Leszek Swirski authored
This reverts commit e4bbf92b. Reason for revert: Crashes: https://build.chromium.org/p/client.v8/builders/V8%20Linux64/builds/19156 Original change's description: > [compiler-dispatcher] Make compiler jobs abstract > > Makes compiler dispatcher jobs an abstract interface, with unoptimized > compile jobs as an implementation of this interface. > > Bug: v8:6537 > Change-Id: I6569060a89c92d35e4bc7962623f77082a354934 > Reviewed-on: https://chromium-review.googlesource.com/558290 > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#46931} TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org Change-Id: I023c0455929180fdcde3caf581f483f794ca2368 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6537 Reviewed-on: https://chromium-review.googlesource.com/589153Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46932}
-
Leszek Swirski authored
Makes compiler dispatcher jobs an abstract interface, with unoptimized compile jobs as an implementation of this interface. Bug: v8:6537 Change-Id: I6569060a89c92d35e4bc7962623f77082a354934 Reviewed-on: https://chromium-review.googlesource.com/558290Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#46931}
-