-
Dominik Inführ authored
TimeToSafepoint is the time needed for all background threads to enter a safepoint after the GC was started on the main thread. This CL improves that metric during concurrent compilation to bytecode by doing: 1) Park the LocalIsolate during InterpreterCompilationJob::ExecuteJobImpl. There are no concurrent heap accesses happening while generating bytecode for now. So instead of manually placing Safepoint() invocations in the code, simply park the local isolate. 2) Destroy the LocalIsolate before the ReleaseParser operation. I've seen this take around 2ms, which regressed TimeToSafepoint a lot. 3) Add explicit safepoints to concurrent allocations. This covers the rest of the code and from what I've seen so far this is good enough to keep TimeToSafepoint around a few microseconds. I've still seen TimeToSafepoint events with 20-80 microseconds but those were quite rare and always seemed to be related to Turbofan. AsLocalIsolate() is necessary in generic code to convert both Isolate and LocalIsolate to LocalIsolate. Bug: v8:10315 Change-Id: Idaf9f04ffdf850d0ab0081ec372cc384a9fe7ef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2663159Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#72618}
d5416b99