- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 04 Apr, 2022 2 commits
-
-
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
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 1 commit
-
-
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}
-
- 31 Mar, 2022 1 commit
-
-
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 1 commit
-
-
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}
-
- 25 Mar, 2022 1 commit
-
-
legendecas authored
Implement WrappedFunction properties name/length. Bug: v8:11989 Change-Id: I050af5814537552ef6c2077802ffc726f2e08fa3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3507201Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#79628}
-
- 02 Mar, 2022 2 commits
-
-
Jakob Gruber authored
When --maglev is set, tier up to Maglev from unoptimized tiers based on --interrupt-budget-for-maglev, initially set to 40KB (which should very roughly by 1/10th of the time until the TF tierup decision is made). On the first interrupt, a non-concurrent optimization to Maglev is requested, which the next call to the marked function will perform. - There is no support for tiering from Maglev to TF yet. - Maglev's language support is minimal and tests are not expected to pass with --maglev. - Disable --maglev by default for now. Drive-by: fixes related to Maglev flag definitions. Bug: v8:7700 Change-Id: I121bb3f4f3830fdd20e1d4a12d3e04f08a99be38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3500302Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79328}
-
Jakob Gruber authored
.. by moving them all to TieringManager. Bug: v8:7700 Change-Id: I03eb2d1607b06ece84a1ca98ebc723788dbc0cde Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3500220 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@{#79325}
-
- 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}
-
- 25 Feb, 2022 1 commit
-
-
legendecas authored
Bootstrap ShadowRealm.prototype.evaluate, WrappedFunction and WrappedFunction.[[Call]]. Bug: v8:11989 Change-Id: Id380acb71cd5719e783c8f5d741cc4ccf2a93e78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432729Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#79293}
-
- 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}
-
- 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}
-
- 14 Dec, 2021 1 commit
-
-
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}
-
- 08 Nov, 2021 1 commit
-
-
Igor Sheludko authored
This CL * adds forwarding accessors to CodeDataContainer for certain widely used Code object's fields and predicates, * adds JSFunction::set_code() overloads accepting CodeT values, * migrates SharedFunctionInfo getters to CodeT, * migrates InterpreterData::interpreter_trampoline to CodeT. Drive-by-fix: replace #if V8_EXTERNAL_CODE_SPACE with #ifdef to be consistent. Bug: v8:11880 Change-Id: I1e114076a0568068038ca6f70a86431a3a9cfb9f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3262716 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77762}
-
- 07 Oct, 2021 1 commit
-
-
Jakob Gruber authored
Certain collators and subject strings may take this new fast path without calling into the (slow) ICU comparison functions. This CL can be roughly split into three topics: 1. The fast path check, precomputed and implemented as a whitelist on the current locale string. 2. The actual fast path, which checks subject string eligibility and performs L1 and L3 collation weight comparisons all in one pass. 3. Resuming from an aborted fast-path into the generic path. A longer overview is available at https://docs.google.com/document/d/1oyDwjYn2JyHsx2YnJJKhjX0WMNQXb8ao86-DRzqiYNg/edit?usp=sharing JetStream2/cdjs scores improve by roughly 40%. Bug: v8:12196 Change-Id: I5e1bbd731a36c361af9667f9104d6fa15c42e117 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3149463Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77284}
-
- 29 Sep, 2021 1 commit
-
-
Seth Brenith authored
Nobody uses the generated *_FIELDS macros anymore, so we can remove them. I also renamed the generated file to represent its content better. Bug: v8:7793 Change-Id: I49ab39e363d6961e7210cd67018b6fb83b65a162 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3192191Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77151}
-
- 30 Aug, 2021 1 commit
-
-
Seth Brenith authored
Most Torque-defined extern classes already use CPP class generation. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. A couple of minor fixes in the Torque compiler were required so that it generates correct code for shapes. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I7e6087153a18d6ee80e67926793e8ba8e01d501e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015666Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Anton Bikineev <bikineev@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#76586}
-
- 24 Aug, 2021 1 commit
-
-
Georg Neis authored
Fixed: chromium:1236286 Change-Id: I90106fce4d6e747f35c638ab00bf9a1696c8eb77 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3109668 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76462}
-
- 29 Jul, 2021 1 commit
-
-
Mythri A authored
Introduce a flush_baseline_code flag to control if baseline code is flushed or not. Currently flush_baseline_code implies flush_bytecode as well. So if flush_baseline_code is enabled both bytecode and baseline code are flushed. If the flag is disabled we only flush bytecode and not baseline code. In a follow-up CL we will add support to control baseline and bytecode flushing independently i.e. we can flush only bytecode / only baseline code / both. Bug: v8:11947 Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/master@{#76003}
-
- 20 Jul, 2021 1 commit
-
-
Mythri A authored
This is a reland of ea55438a. Relanding after a fix lands here: https://chromium-review.googlesource.com/c/v8/v8/+/3030711. The failures were caused because baseline code could be flushed during the process of deoptimization after we choose which entry (InterpreterEnterAt* / BaselineEnterAt* ) builtin to use. BaselineEnterAt* builtins expect baseline code but it could be flushed before we execute the builtin. The fix is to defer the decision. Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I63dce4cd9f6271c54049cc09f95d12e2795f15d1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035774Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75810}
-
- 19 Jul, 2021 1 commit
-
-
Jakob Gruber authored
This wraps up the transition away from kSerialized ref kinds. Since JSFunctionRef is a complex type, we don't attempt full consistency on the background thread. Instead, we serialize functions on the background in a partially-racy manner, in which consistency between different JSFunction fields is *not* guaranteed. Consistency is later verified through a new compilation dependency kind during finalization. Bug: v8:7790, v8:12004 Change-Id: Ic2b78af9c9fe183c8769d323132bb304b151dc75 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968404 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75789}
-
- 12 Jul, 2021 2 commits
-
-
Mythri Alle authored
This reverts commit ea55438a. Reason for revert: Likely culprit for these failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20NumFuzz/15494/overview Original change's description: > [sparkplug] Support bytecode / baseline code flushing with sparkplug > > Currently with sparkplug we don't flush bytecode / baseline code of > functions that were tiered up to sparkplug. This CL adds the support to > flush baseline code / bytecode of functions that have baseline code too. > This CL: > 1. Updates the BodyDescriptor of JSFunction to treat the Code field of > JSFunction as a custom weak pointer where the code is treated as weak if > the bytecode corresponding to this function is old. > 2. Updates GC to handle the functions that had a weak code object during > the atomic phase of GC. > 3. Updates the check for old bytecode to also consider when there is > baseline code on the function. > > This CL doesn't change any heuristics for flushing. The baseline code > will be flushed at the same time as bytecode. > > Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a > Bug: v8:11947 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 > Commit-Queue: Mythri Alle <mythria@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75674} Bug: v8:11947 Change-Id: I50535b9a6c6fc39eceb4f6c0e0c84c55bb92f30a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3017811Reviewed-by: Mythri Alle <mythria@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#75679}
-
Mythri A authored
Currently with sparkplug we don't flush bytecode / baseline code of functions that were tiered up to sparkplug. This CL adds the support to flush baseline code / bytecode of functions that have baseline code too. This CL: 1. Updates the BodyDescriptor of JSFunction to treat the Code field of JSFunction as a custom weak pointer where the code is treated as weak if the bytecode corresponding to this function is old. 2. Updates GC to handle the functions that had a weak code object during the atomic phase of GC. 3. Updates the check for old bytecode to also consider when there is baseline code on the function. This CL doesn't change any heuristics for flushing. The baseline code will be flushed at the same time as bytecode. Change-Id: I6b51e06ebadb917b9f4b0f43f2afebd7f64cd26a Bug: v8:11947 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2992715 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75674}
-
- 22 Jun, 2021 1 commit
-
-
Georg Neis authored
It was not in sync with the optimization, which relies on inspecting up the length and name fields even for bound functions. To make a now meaningful serializer test actually pass, I have to to make some changes to the test setup. I'm also moving the function name and length index constants from JSFunction to JSFunctionOrBoundFunction for clarity. TBR=marja@chromium.org Bug: v8:7790 Change-Id: I36dd3c80996ccb53810c7ea9bfceb5c84ffd60ab Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972919 Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#75299}
-
- 17 Jun, 2021 1 commit
-
-
Igor Sheludko authored
This CL adds - CodeT type - an alias for CodeDataContainer or Code depending on whether the v8_enable_external_code_space is enabled or not, - a set of conversion functions from CodeT to Code or CodeDataContainer and back (both in C++ and CodeStubAssembler), - masm support for calling/tailcalling via CallDataContainer which contain the code entry point address, - masm support for calling/tailcalling via CodeT. Bug: v8:11880 Change-Id: Ib36f4c6db69ec49aaea29412647e59ada95da19b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2967463 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75207}
-
- 15 Jun, 2021 1 commit
-
-
Igor Sheludko authored
... to ensure that it'll not be triggered for Code objects which are known to never be in new space. This removes the need for having custom implementation of setters with Code values - existing [CONDITIONAL_]WRITE_BARRIER macros will work just fine. Bug: v8:11879, v8:11880 Change-Id: I7ed70e51f9459040086dd4c67e61b11617dbdc24 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2964812Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75166}
-
- 07 Jun, 2021 1 commit
-
-
Jakob Kummerow authored
instead of recursive. JS code can construct very long chains of nested bound functions or proxies, where the previous recursive implementation could run out of stack space. Fixed: chromium:1214616 Change-Id: I764718f03030d22c0873b3ed05277d4317789093 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2933668 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#74981}
-
- 10 May, 2021 1 commit
-
-
Marja Hölttä authored
Detailed list of changes: https://docs.google.com/document/d/15i4-SZDzFDW7FfclIYuZEhFn-q-KpobCBy23x9zZZLc/edit?usp=sharing Bug: v8:11111 Change-Id: I931003bd4552cf91d57de95af04a427a9e6d6ac9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2814259Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Shu-yu Guo <syg@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#74459}
-
- 04 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
Maps set on the JSFunction were done so in a non-atomic way, which meant that we were failing to have a synchronization point and the read/writes could be reordered. This started happening after a previous CL[1] moved some methods from relaxed to non-atomic, which triggered TSAN (see v8:11696). [1]: https://chromium-review.googlesource.com/c/v8/v8/+/2843359 Bug: v8:7790, v8:11696 Change-Id: I8472ff8b63d391376ee2f1dcf0a8b4fd7cecfcd1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2851893Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74357}
-
- 26 Apr, 2021 1 commit
-
-
Leszek Swirski authored
It's unfortunate that there is both a LocalIsolate template parameter, and an actual LocalIsolate class. Clean this up by renaming the template parameters to IsolateT Change-Id: Iecefc3eca5aeb7bbd21e78818b90f9e75cdff10f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846880 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#74173}
-
- 15 Apr, 2021 1 commit
-
-
Jakob Gruber authored
Some logic still remains, notably in compiler/. Bug: v8:8888 Change-Id: I7e7f10a487e1bc8b90bbbfedbc46bf09bae0717e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2825589 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#73969}
-
- 31 Mar, 2021 1 commit
-
-
Camillo Bruni authored
Bug: v8:11263 Change-Id: Ia98fc29c52e68ba3a7dcdcdc1a06ce1192b10f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2787487Reviewed-by: Omer Katz <omerkatz@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73754}
-
- 17 Mar, 2021 2 commits
-
-
Santiago Aboy Solanes authored
We have it readily available at all call-sites. There is no need to request it via GetIsolate on the function itself. Change-Id: I4936177c47c8adf9dfeafe1e320f8411ae358a5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2761200Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#73470}
-
Santiago Aboy Solanes authored
We can ensure that the constructor is set before the map is set on the JSObject. Setting the constructor remains non-atomic. Bug: v8:7790 Change-Id: Ie65519f61e29c9bed89bf09f582aa8bd39de1b03 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2761199Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#73460}
-
- 23 Feb, 2021 1 commit
-
-
Leszek Swirski authored
Baseline code is, like baseline frames, now considered unoptimized, sharing this name with interpreted code. Bug: v8:11420,v8:11429 Change-Id: If1f4a41725dd0d809a4412f5d2f827d19f9628fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2713102 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72959}
-
- 22 Feb, 2021 1 commit
-
-
Mythri A authored
Earlier we used the same interrupt budget always and waited for higher number of ticks when tiering up from Turboprop to TurboFan. On some of the real world pages this adds a reasonable overhead for processing these interrupts. This cl sets the interrupt budget to a higher value so there are fewer interrupts. This cl: 1. Sets the interrupt budget on feedback cell to FLAG_interrupt_budget * scale factor when we install optimized code. 2. Resets the budget to FLAG_interrupt_budget when there is a deoptimization. 3. Updates the runtime profiler to remove the scaling of number of ticks needed for optimization when tiering up from TP to TF. On sheets benchmark, we spend 40-50ms when servicing interrupts from Turboprop code. This change brings it down to ~7ms. We also see improvements on other pages. Bug: v8:9684 Change-Id: Ia3e5e998d1fff44f2e08a240a8769b7ebe794da2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2696661 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72906}
-
- 19 Feb, 2021 1 commit
-
-
Mike Stanton authored
Code objects are exposed through JSFunction and SharedFunctionInfo. If they are builtins, we don't have to worry about background threads seeing partially initialized code objects. If they are optimized code objects, we may. Background threads read the code fields with AcquireLoad semantics. The fields are set on the main thread with ReleaseStore semantics when appropriate. Special care is taken when setting an optimized code object in a closure in the interpreter entry stub. Since the MacroAssembler doesn't support ReleaseStore semantics, this CL ensures that the optimized code object is stored with those semantics in the feedback vector, where the interpreter entry stub finds it. Bug: v8:7790 Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633 Commit-Queue: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72869}
-
- 12 Feb, 2021 2 commits
-
-
Benedikt Meurer authored
As outlined in the design document linked below, we're removing the support for the non-standard Function.displayName property for the purpose of Error.stack and DevTools Inspector stack traces. The motivation here is that the negative lookup is costly, and we have Function.name as a standard alternative (configurable since ES6 for exactly this reason). I dediced to go with JSFunction::GetDebugName(), since JSFunction::GetName() was confusing in that it'd only get the "name" property's value if it's a data property, but not with accessors. JSFunction::GetDebugName() makes it clear that this is really a debug helper function and might not give you the "name" property value. Doc: https://bit.ly/devtools-function-displayName-removal Bug: v8:8742, chromium:1177685, chromium:1077657, chromium:17356 Change-Id: I7717585cbace626174b2f2ed2a4f68f75429eca1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692189 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72715}
-
Leszek Swirski authored
Currently we sometimes refer to baseline code or the baseline compiler by its codename (Sparkplug). The codename is fun, but we should be consistent and call things by one name or the other. Following the pattern of Ignition stuff being called "interpreter", we call Sparkplug "baseline", and leave the codename only in flags and variants. Bug: v8:11420 Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72696}
-