- 11 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This is a reland of commit 51b99213 Fixed in reland: - bytecode_age was incorrectly still accessed as an int8 (instead of int16). - age and osr state were incorrectly reset on ia32 (16-bit write instead of 32-bit). Original change's description: > [osr] Add an install-by-offset mechanism > > .. for concurrent OSR. There, the challenge is to hit the correct > JumpLoop bytecode once compilation completes, since execution has > moved on in the meantime. > > This CL adds a new mechanism to request installation at a specific > bytecode offset. We add a new `osr_install_target` field to the > BytecodeArray: > > bitfield struct OSRUrgencyAndInstallTarget extends uint16 { > osr_urgency: uint32: 3 bit; > osr_install_target: uint32: 13 bit; > } > > // [...] > osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; > bytecode_age: uint16; // Only 3 bits used. > // [...] > > Note urgency and install target are packed into one 16 bit field, > we can thus merge both checks into one comparison within JumpLoop. > Note also that these fields are adjacent to the bytecode age; we > still reset both OSR state and age with a single (now 32-bit) > store. > > The install target is the lowest 13 bits of the bytecode offset. > When set, every reached JumpLoop will check `is this my offset?`, > and if yes, jump into runtime to tier up. > > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. > > Bug: v8:12161 > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79853} Bug: v8:12161 Change-Id: I7c59b2a2aacb1d7d40fdf39396ec9d8d48b0b9ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578543Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79911}
-
- 08 Apr, 2022 1 commit
-
-
Leszek Swirski authored
This allows us to inject maglev compilations into perf profiles. Bug: v8:7700 Change-Id: Ic1f2671835ca231cd954124db325a5ab8480bee0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579101 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79886}
-
- 07 Apr, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 51b99213. Reason for revert: Speculative revert for MSAN failure https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/43080/overview Original change's description: > [osr] Add an install-by-offset mechanism > > .. for concurrent OSR. There, the challenge is to hit the correct > JumpLoop bytecode once compilation completes, since execution has > moved on in the meantime. > > This CL adds a new mechanism to request installation at a specific > bytecode offset. We add a new `osr_install_target` field to the > BytecodeArray: > > bitfield struct OSRUrgencyAndInstallTarget extends uint16 { > osr_urgency: uint32: 3 bit; > osr_install_target: uint32: 13 bit; > } > > // [...] > osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; > bytecode_age: uint16; // Only 3 bits used. > // [...] > > Note urgency and install target are packed into one 16 bit field, > we can thus merge both checks into one comparison within JumpLoop. > Note also that these fields are adjacent to the bytecode age; we > still reset both OSR state and age with a single (now 32-bit) > store. > > The install target is the lowest 13 bits of the bytecode offset. > When set, every reached JumpLoop will check `is this my offset?`, > and if yes, jump into runtime to tier up. > > Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. > > Bug: v8:12161 > Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79853} Bug: v8:12161 Change-Id: I0c47499544465c80b5b23a492c00ec1c62815caa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576121 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#79855}
-
Jakob Gruber authored
.. for concurrent OSR. There, the challenge is to hit the correct JumpLoop bytecode once compilation completes, since execution has moved on in the meantime. This CL adds a new mechanism to request installation at a specific bytecode offset. We add a new `osr_install_target` field to the BytecodeArray: bitfield struct OSRUrgencyAndInstallTarget extends uint16 { osr_urgency: uint32: 3 bit; osr_install_target: uint32: 13 bit; } // [...] osr_urgency_and_install_target: OSRUrgencyAndInstallTarget; bytecode_age: uint16; // Only 3 bits used. // [...] Note urgency and install target are packed into one 16 bit field, we can thus merge both checks into one comparison within JumpLoop. Note also that these fields are adjacent to the bytecode age; we still reset both OSR state and age with a single (now 32-bit) store. The install target is the lowest 13 bits of the bytecode offset. When set, every reached JumpLoop will check `is this my offset?`, and if yes, jump into runtime to tier up. Drive-by: Rename BaselineAssembler::LoadByteField to LoadWord8Field. Bug: v8:12161 Change-Id: I275d468b19df3a4816392a2fec0713a8d211ef80 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571812Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79853}
-
- 06 Apr, 2022 1 commit
-
-
Jakob Gruber authored
This flag was a leftover from very early Turbofan days and serves no purpose. Non-OSR TF code automatically uses function context specialization (FCS) when appropriate without looking at the flag value. OSR TF code should never use FCS since it is cached by the SharedFunctionInfo (not by the JSFunction). Bug: v8:12161 Change-Id: Ifb5a10918dbdf34a7164f7e665a230698b793e9e Fixed: chromium:1313419 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571895 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79802}
-
- 04 Apr, 2022 5 commits
-
-
Jakob Gruber authored
.. to simplify logic within compiler.cc. GetOrCompileOptimized now only returns Code object if the requested optimized Code object is available. This change also required updating CompileLazy to install the appropriate Code object before potentially calling CompileOptimized_* runtime functions in order to satisfy the is_compiled precondition. Bug: v8:12161 Change-Id: I991dbcc0ba8f3d635aa1e1f06e4cffd89e08a47b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3562978Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79762}
-
Jakob Gruber authored
If we've already cached OSR'd code for the current function but with a different osr offset, fall back to synchronous compilation. This avoids degenerate cases where we repeatedly spawn OSR jobs but then fail to install them. Drive-by: More consistent --trace-osr output. Drive-by: Rename kCompileForOnStackReplacement to kCompileOptimizeOSR for name consistency. Drive-by: Add JSFunction::DebugNameCStr() for more convenient PrintF's. Bug: v8:12161 Change-Id: I2b4a65bc9e082d85d7048a3e92ef86b07d396687 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560431Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79761}
-
Jakob Gruber authored
Tweak a few names, remove a few GetIsolate calls, other minor usability refactors. It may be worth taking a closer look at the impl in the future, currently the design choices don't seem ideal (see the added TODO on top of the class). The reland is unchanged from the original CL. Bug: v8:12161 Change-Id: I9971f7f2fb08b7a1ec2d57b2a0e4accdc11191ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568444Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79759}
-
Jakob Gruber authored
- Unhandlify OSROptimizedCodeCache::GetOptimizedCode. - Unstatic-fy FeedbackVector::SetOptimizedCode. - Remove frame-walking logic during the OSR tierup decision. The reland is unchanged from the original CL. Bug: v8:12161 Change-Id: Ibf03a9dd9a6fcd38c0664e5d5014a26d0240e035 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568463Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79752}
-
Jakob Gruber authored
This is a reland of commit 3ce690ee Changed for the reland: - Remove the currently-unused BytecodeArray member to avoid MSAN failures. - s/return/continue/ in optimizing-compile-dispatcher. Original change's description: > [osr] Basic support for concurrent OSR > > This CL adds basic support behind --concurrent-osr, > disabled by default. > > When enabled: > 1) the first OSR request starts a concurrent OSR compile job. > 2) on completion, the code object is inserted into the OSR cache. > 3) the next OSR request picks up the cached code (assuming the request > came from the same JumpLoop bytecode). > > We add a new osr optimization marker on the feedback vector to > track whether an OSR compile is currently in progress. > > One fundamental issue remains: step 3) above is not guaranteed to > hit the same JumpLoop, and a mismatch means the OSR'd code cannot > be installed. This will be addressed in a followup by targeting > specific bytecode offsets for the install request. > > This change is based on fanchen.kong@intel.com's earlier > change crrev.com/c/3369361, thank you! > > Bug: v8:12161 > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79685} Bug: v8:12161 Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79746}
-
- 01 Apr, 2022 3 commits
-
-
Adam Klein authored
This reverts commit 3ce690ee. Reason for revert: failures on CrOS MSan build: https://crbug.com/1312188 Original change's description: > [osr] Basic support for concurrent OSR > > This CL adds basic support behind --concurrent-osr, > disabled by default. > > When enabled: > 1) the first OSR request starts a concurrent OSR compile job. > 2) on completion, the code object is inserted into the OSR cache. > 3) the next OSR request picks up the cached code (assuming the request > came from the same JumpLoop bytecode). > > We add a new osr optimization marker on the feedback vector to > track whether an OSR compile is currently in progress. > > One fundamental issue remains: step 3) above is not guaranteed to > hit the same JumpLoop, and a mismatch means the OSR'd code cannot > be installed. This will be addressed in a followup by targeting > specific bytecode offsets for the install request. > > This change is based on fanchen.kong@intel.com's earlier > change crrev.com/c/3369361, thank you! > > Bug: v8:12161 > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79685} Bug: v8:12161, chromium:1312188 Change-Id: Iac1e3fd67ecc658a1cdee8f4d13354c097ed6697 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564983 Auto-Submit: Adam Klein <adamk@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#79702}
-
Adam Klein authored
This reverts commit dc9b48e4. Reason for revert: https://crbug.com/1312188 Original change's description: > Address comments from `[osr] Basic support for concurrent OSR` > > - Unhandlify OSROptimizedCodeCache::GetOptimizedCode. > - Unstatic-fy FeedbackVector::SetOptimizedCode. > - Remove frame-walking logic during the OSR tierup decision. > > Bug: v8:12161 > Change-Id: I4fa8c972cb50d369b17898ba57e1909c86e933df > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560478 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79686} Bug: v8:12161, chromium:1312188 Change-Id: Ia64c4204f9f65f19aa858c61f32658cee310033e No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564990 Auto-Submit: Adam Klein <adamk@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#79701}
-
Adam Klein authored
This reverts commit d368dcf4. Reason for revert: https://crbug.com/1312188 Original change's description: > Refactor OSROptimizedCodeCache > > Tweak a few names, remove a few GetIsolate calls, other minor > usability refactors. > > It may be worth taking a closer look at the impl in the future, > currently the design choices don't seem ideal (see the added TODO > on top of the class). > > Bug: v8:12161 > Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79687} Bug: v8:12161, chromium:1312188 Change-Id: Ieb3a91682845a23536fdfdf3208af74b3c6585f8 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3564989 Auto-Submit: Adam Klein <adamk@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#79700}
-
- 31 Mar, 2022 3 commits
-
-
Jakob Gruber authored
Tweak a few names, remove a few GetIsolate calls, other minor usability refactors. It may be worth taking a closer look at the impl in the future, currently the design choices don't seem ideal (see the added TODO on top of the class). Bug: v8:12161 Change-Id: Ib34e372aa58a30c68c9c5cdd0d1da0ec3e86717c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560447Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79687}
-
Jakob Gruber authored
- Unhandlify OSROptimizedCodeCache::GetOptimizedCode. - Unstatic-fy FeedbackVector::SetOptimizedCode. - Remove frame-walking logic during the OSR tierup decision. Bug: v8:12161 Change-Id: I4fa8c972cb50d369b17898ba57e1909c86e933df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560478Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79686}
-
Jakob Gruber authored
This CL adds basic support behind --concurrent-osr, disabled by default. When enabled: 1) the first OSR request starts a concurrent OSR compile job. 2) on completion, the code object is inserted into the OSR cache. 3) the next OSR request picks up the cached code (assuming the request came from the same JumpLoop bytecode). We add a new osr optimization marker on the feedback vector to track whether an OSR compile is currently in progress. One fundamental issue remains: step 3) above is not guaranteed to hit the same JumpLoop, and a mismatch means the OSR'd code cannot be installed. This will be addressed in a followup by targeting specific bytecode offsets for the install request. This change is based on fanchen.kong@intel.com's earlier change crrev.com/c/3369361, thank you! Bug: v8:12161 Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79685}
-
- 30 Mar, 2022 2 commits
-
-
Jakob Gruber authored
.. with readability and simplicity in mind. - Rename OptimizationMarker to the (shorter) TieringState. 'Tiering' also matches 'TieringManager' terminology. - Rename the values: kNone -> kNone kInOptimizationQueue -> kInProgress kCompileFoo_NotConcurrent -> kRequestFoo_Synchronous kCompileFoo_Concurrent -> kRequestFoo_Concurrent - Likewise rename ConcurrencyMode::kNotConcurrent to kSynchronous. - Add predicates to test enum values. - Consistent lower case names for accessors on JSFunction and FeedbackVector. - Instead of having to call HasOptimizationMarker() before using any other accessor, simply have optimization_marker() return kNone if no feedback vector exists. - Drive-by: Enable the Unreachable() in MaybeOptimizeCode() unconditionally - this should never happen, there's no reason not to protect against this in release builds as well. Bug: v8:12161 Change-Id: I67c03e2b7bd0a6b86d0c64f504ad8cb47e9e26ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3555774Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79669}
-
Pan, Tao authored
There are two kinds of method to get native context of JSFunction object, directly calling to native_context() and calling context().native_context(). Replace all context().native_context() with native_context(). Change-Id: Ia7a7e64648446002717d38fafecd2420f622325e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541468Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Tao Pan <tao.pan@intel.com> Cr-Commit-Position: refs/heads/main@{#79663}
-
- 23 Mar, 2022 1 commit
-
-
Benedikt Meurer authored
Following up on https://crrev.com/c/3540145, this also changes local debug evaluate scripts to be marked as shared-cross-origin. Drive-by-fix: This also updates the test for global debug evaluate to use the official (debug) API instead of peaking into the V8 internals unnecessarily. Bug: chromium:1295750 Change-Id: Ief0bc76a4333671f8db761d1f6a5fb740aae698e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3541780Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#79568}
-
- 18 Mar, 2022 1 commit
-
-
Victor Gomes authored
Fixes bazel bot issue: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20bazel%20-%20builder/1279/overview Bug: v8:7700 Change-Id: I4a7b43517574fc99bed2fe2bd75c126d06fcfad8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3535790 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#79530}
-
- 17 Mar, 2022 2 commits
-
-
Jakob Gruber authored
.. into new virtual subclass TurbofanCompilationJob. Update all TF code to derive from this class. Specifically, the OptimizedCompilationInfo is TF-specific and now lives in TurbofanCompilationJob. The motivation behind this is that Maglev now also uses this infrastructure. Drive-by: Replace CompilationMode with ConcurrencyMode. Bug: v8:7700 Change-Id: Iae6d1ffd1c810e2e45cad6c9b4e43d4c82ac54a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528493Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#79515}
-
Jakob Gruber authored
- Restructure the runtime function implementation. - Rename osr_loop_nesting_level to osr_urgency and add helpers. The motivation for the latter: I've always struggled with the `osr_loop_nesting_level` term; it neither matches terminology of what it's compared against (= the loop depth), nor implies what it's used for (= osr is triggered when `loop depth < osr nesting level`). In this CL it's renamed to `osr_urgency` to reflect that as urgency rises, we consider more and more loops as OSR candidates. Bug: v8:12161 Change-Id: I194ec5a3f1f02526641af1c7796ee0956b6fd3a1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3528735Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79509}
-
- 16 Mar, 2022 1 commit
-
-
Jakob Gruber authored
This CL implements most parts of the concurrent maglev pipeline. - MaglevConcurrentDispatcher: controls concurrent jobs. - MaglevCompilationInfo: holds job-global data, controls handle fiddling between the main isolate and local isolates, owns job-global state like the Zone. - MaglevCompilationUnit: same as before, holds per-unit data. Still missing: job finalization. Bug: v8:7700 Change-Id: I281178d945e79a0ba97fa2ac7023285d84a16641 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3516036Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79489}
-
- 02 Mar, 2022 1 commit
-
-
Seth Brenith authored
Currently, a streamed script which specifies 'use strict' is stored in the isolate script cache with a key indicating that it is strict mode. However, the keys should be based on the context executing the script, not the content of the script, so that the next lookup can find the entry without having to parse the script first. Bug: v8:12668 Change-Id: Iaa76c00c431ad54a86ffd18b61cb4f67dc457b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3498220Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#79331}
-
- 01 Mar, 2022 1 commit
-
-
Jakob Gruber authored
- Add the Isolate as an explicit param (we already have it at all callsites) - Pass an explicit CodeKind param to MarkForOptimization in preparation for Maglev. - Split EnsureFeedbackVector into that, plus CreateAndAttachFeedbackVector for when we know it has to be created. Bug: v8:7700 Change-Id: Ie9022deccd31d472d6df3d442b25583af5569ab0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497383 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79318}
-
- 24 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Maglev is mid-tier optimising compiler designed mainly for compilation speed that can still generate good code for straightforward JS. This initial commit is an MVP for Maglev which can compile and run some very simple code, and sets up a framework that we can build upon. Design: https://docs.google.com/document/d/13CwgSL4yawxuYg3iNlM-4ZPCB8RgJya6b8H_E2F-Aek/edit# Bug: v8:7700 Change-Id: I5ae074ae099126c2c0d50864ac9b3d6fa5c9e85a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483664Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79247}
-
- 21 Feb, 2022 2 commits
-
-
Leszek Swirski authored
This reverts commit 9f902b74. Reason for revert: Reverting due to various fuzzing issues (numfuzz issues listed in original CL comments, ochang fuzzer in https://bugs.chromium.org/p/chromium/issues/detail?id=1299418) Original change's description: > [turbofan] Making OSR concurrent > > ... to reduce compilation overhead on the main thread for OSR > > Bug: v8:12161 > Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> > Cr-Commit-Position: refs/heads/main@{#79188} Bug: v8:12161 Change-Id: Id6f6086517cd77fb1aa60b20fd03528b8e2ca686 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3477104 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79194}
-
Fanchen Kong authored
... to reduce compilation overhead on the main thread for OSR Bug: v8:12161 Change-Id: I54ca5fa6201405daf92dac9cf51d5de4b46577b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3369361Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Fanchen Kong <fanchen.kong@intel.com> Cr-Commit-Position: refs/heads/main@{#79188}
-
- 16 Feb, 2022 1 commit
-
-
Jakob Gruber authored
This predicate is just confusing - it's a renamed version of HasBytecodeArray; but HasBytecodeArray also returns true if the SFI has attached Sparkplug code - and is thus not interpreted. Simply replace it by HasBytecodeArray. Bug: v8:7700 Change-Id: Id4be2048a625142ade1096044133d9cd2896b51d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3461935Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79115}
-
- 15 Feb, 2022 2 commits
-
-
Jakob Gruber authored
This was mostly unused. We should simply be able to use CodeKind plus related predicates instead. Replace FeedbackVector::optimization_tier with maybe_has_optimized_code, which states whether the optimized code cache is filled. The value is updated lazily and may lag behind the actual code cache state. We only use this field for quick cache-empty? checks from generated code. Bug: v8:7700,v8:12552 Change-Id: Ibfc5c0128eac56167a68ecba5690eab2e9369640 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460741Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79107}
-
Jakob Gruber authored
.. to resolve the overloaded 'runtime' term and overall pick a more meaningful name for this class. It's neither very related to runtime (instead it's called periodically when the bytecode interrupt budget is exhausted); nor is profiling its main purpose. This class is responsible for controlling tiering decisions, hence the new name 'TieringManager'. Bug: v8:7700 Change-Id: Id6f1edf4ebe016d0d81903d0a13e0e1fe6e02142 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463716Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79101}
-
- 05 Feb, 2022 1 commit
-
-
Shu-yu Guo authored
Currently the Isolate is gotten off of the object that the operation is being performed on. Shared objects return the shared Isolate, which is incorrect as it shouldn't be used to run JS, nor does it have HandleScopes open. Plumb the executing Isolate through. Bug: v8:12547 Change-Id: I428d21f5e6a9c51c8c7c4577395bf27c8706bdb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3441033Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78963}
-
- 27 Jan, 2022 1 commit
-
-
Jakob Gruber authored
The functionality is unused and we are simplifying OptimizationMarker usage. Drive-by: Remove unused return value of Compiler::CompileOptimized. Drive-by: Don't add kStackSpaceRequiredForCompilation as gap to the stack check when compiling concurrently, i.e. on another thread. Bug: chromium:757467 Change-Id: Ibbe204b82bf937b9eb74f9eb2c3fd2d719d53ef9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3416245Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78800}
-
- 20 Jan, 2022 1 commit
-
-
Jakob Gruber authored
Bug: v8:12552 Change-Id: I99e4d8e8aeba5460f11e54cc1b2bcaea98a5276d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400964Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#78698}
-
- 17 Jan, 2022 1 commit
-
-
Marja Hölttä authored
Give the "phantom" script containing the web snapshot functions the same name as the original script. Bug: v8:11525 Change-Id: Iae77d58152642256560ceb3688bc2b3d0d9800be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394707Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#78643}
-
- 16 Dec, 2021 2 commits
-
-
Igor Sheludko authored
This CL * removes Builtins::codet() and Builtins::codet_handle() returning builtins as CodeT objects in favor of code() and code_handle(), * removes BUILTIN_CODET macro in favor of BUILTIN_CODE, * removes CodeDataContainer table. Bug: v8:11880 Change-Id: Ic868549030744b0ff3ea5d5edbfcacf77c6de96d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3344650Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78399}
-
Igor Sheludko authored
... in order to avoid Code <-> CodeT conversions in builtins. This CL changes the meaning of RelocInfo::CODE_TARGET which now expects CodeT objects as a code target. In order to reduce code churn this CL makes BUILTIN_CODE and friends return CodeT instead of Code. In the follow-up CLs BUILTIN_CODET and friends will be removed. Bug: v8:11880 Change-Id: Ib8f60973e55c60fc62ba84707471da388f8201b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3338483Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78393}
-
- 14 Dec, 2021 2 commits
-
-
Igor Sheludko authored
This CL * migrates FeedbackVector::optimized_code to CodeT, * migrates OSROptimizedCodeCache to CodeT. Bug: v8:11880 Change-Id: I2082412fb9fdf90e7ed90f4454ecf55f4f3d53d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330468Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78367}
-
Igor Sheludko authored
This CL migrates JSFunction's code accessors to CodeT. Bug: v8:11880 Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78365}
-
- 10 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Rather than requiring the user of a LocalIsolate to pass in a RuntimeCallStats from a WorkerThreadRuntimeCallStatsScope, create the scope in the LocalIsolate directly and use its RuntimeCallStats in the LocalIsolate constructor. We can't do this for the main thread LocalIsolate, since WorkerThreadRuntimeCallStatsScope doesn't work on the main thread, so there we use the main-thread RuntimeCallStats instead. This flushes out some issues of background-thread LocalIsolates being used on the main thread, so fix those too, as well as RCS scopes using background counters for operations that could happen on the main thread. Change-Id: I21a53be0771f47a03ccdb27d24c2b9d25d8b2d1c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318664Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78334}
-