- 11 Feb, 2020 1 commit
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/8ada491..9e32f61 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/3b8094a..64c5af3 Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/7d1284a..10a302f TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Ia023508780e6341f22d94e9879fbae24e1fff960 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2049523Reviewed-by:
v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Commit-Queue: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#66211}
-
- 10 Feb, 2020 20 commits
-
-
Milad Farazmand authored
Port 9d3dc6f2 Original Commit Message: FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. R=solanes@chromium.org, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If797a8acba7581c9c388ac09b5554c774c5993a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2048124Reviewed-by:
Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#66210}
-
Dominik Inführ authored
Add CHECKs to make sure that ArrayBufferSweeper is only active when v8_enable_array_buffer_extension is set to true. Bug: v8:10064 Change-Id: I609d5e1230dca52fd8555d4401c3f60faf4c266c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047047Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#66209}
-
Shu-yu Guo authored
Deprecate the following explicit FinalizationGroup APIs in favor of automatic handling of FinalizationGroup cleanup callbacks: - v8::Isolate::SetHostCleanupFinalizationGroupCallback - v8::FinaliationGroup::Cleanup If no HostCleanupFinalizationGroupCallback is set, then FinalizationGroup cleanup callbacks are automatically scheduled by V8 itself as non-nestable foreground tasks. When a Context being disposed, all FinalizationGroups that are associated with it are removed from the dirty list, cancelling scheduled cleanup. This is a reland of 31d8ff7a Bug: v8:8179, v8:10190 Change-Id: I704ecf48aeebac1dc2c05ea1c052f6a2560ae332 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045723 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66208}
-
Milad Farazmand authored
Port 86d4b9f6 Original Commit Message: Each assembler has it's own way to place breakpoints: - stop() for arm, mips*, ppc* and s390. - debug() for arm64. - int3() for ia32 and x64. We can mandate a macro-assembler `DebugBreak()` method that all should implement so one can place a breakpoint in a portable way using a macro-assembler. This way also assemblers are in line with TurboFan, CSA, Torque and Liftoff which all have a DebugBreak() facility. R=pierre.langlois@arm.com, joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com BUG= LOG=N Change-Id: If2fb5ed99b4477142579e29fc5288d0768fd48c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047463Reviewed-by:
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
-
Michael Achenbach authored
We should not allow runtime functions that perform extra checks in differential fuzzing, as there we ignore crashes and dchecks entirely. Furthermore, this change whitelists some runtime functions for getting more coverage. Bug: chromium:1044942 Change-Id: Ie5d90bb53bc2d2bacc6635b1dcbe466605b33e12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041444 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#66205}
-
Dominik Inführ authored
Introduce separate counters for young and old array buffer bytes. They are used to keep the counter stable during sweeping when the array buffer lists are moved to the concurrent thread for sweeping. Bug: v8:10064 Change-Id: I0f11a634341873b4d21759c284c55beb26fe30a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2045511 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
Change-Id: If22a3121f3fdaf0e67ecee267ea275b1bc79d617 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039052Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66203}
-
Michael Achenbach authored
This makes creating whitelisted runtime functions more permissive on fuzzers (when --allow-natives-for-fuzzing is passed). - Runtime functions with too few arguments are replaced with undefined. - Superfluous arguments are ignored. This reduces syntax-error rate on fuzzers. Also prevents dcheck errors when fuzzing debug builds and fuzzers use too many arguments for runtime functions. Bug: chromium:1044942 Change-Id: I23b45398421c50bc82d1e8bfdf019f565253db96 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039352 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
-
Ulan Degenbaev authored
This groups atomicops by type, removes an unused atomicop, and fixes comments. Change-Id: I9621ac4512d019ae9d0ce4f7e38c81011d46aa37 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047044Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#66201}
-
Leszek Swirski authored
Make the NextScriptId value incrementing method thread-safe, using CompareAndSwap primitives. This will allow it to be used in the future for off-thread compilation. Bug: chromium:1011762 Change-Id: I5b449e75c7dc63d24fa045ae880b0680b54c2f3d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046883Reviewed-by:
-
Leszek Swirski authored
Take advantage of the HandleOrOffThreadHandle implicit conversions where applicable. Bug: chromium:1011762 Change-Id: Iaf49d9098368b402e1cd3d991629d3f5e718f28e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2046885 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#66199}
-
Pierre Langlois authored
Each assembler has it's own way to place breakpoints: - stop() for arm, mips*, ppc* and s390. - debug() for arm64. - int3() for ia32 and x64. We can mandate a macro-assembler `DebugBreak()` method that all should implement so one can place a breakpoint in a portable way using a macro-assembler. This way also assemblers are in line with TurboFan, CSA, Torque and Liftoff which all have a DebugBreak() facility. Change-Id: Ic4332bd19ca4db53e01441d54af6632c2c1189f1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2020954Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#66198}
-
Leszek Swirski authored
Make Scope allocation and ScopeInfo creation Isolate-templated. This includes making SourceTextModuleInfo allocation templated -- modules aren't currently streamed off-thread, but will hopefully be in the future, so this future-proofs them against that. Bug: chromium:1011762 Change-Id: I8954e08e8e81489eb821b5f62ec35a5be31fce09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043790Reviewed-by:
-
Michael Lippautz authored
When delaying finalization we considered the maximum of the current time to task and the recorded average. In case there's no recorded average the GC would consider the current time to task as estimate which is too aggresive as V8 may never get a task executed. Be fully conservative about recorded task times and bail out in such cases. Bug: chromium:1049957 Change-Id: Ibaac242f72459341a170af80e63fb2266f91b0eb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043809 Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Dominik Inführ authored
Update external memory counters when using ArrayBufferExtensions. In case the array buffers are swept concurrently, the counters are updated at the beginning of the next minor/full GC. A subsequent GC is going to update counters faster. ArrayBufferExtension now stores the accounting_length such that the sweeper always knows how much memory to deduct from the external memory on destruction. ArrayBufferList now also tracks the size of all ArrayBuffers in it. Bug: v8:10064 Change-Id: I50a8b1180aa837b6932f834df1610255bd2bd9fd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041441 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Leszek Swirski authored
Make sure we can't get the Isolate for writable off-thread space objects, to avoid leaking the Isolate into off-thread compilation. Bug: chromium:1011762 Change-Id: I5c4316e751736b8c8235fdcc8949d52b78313f38 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043791 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
-
Joakim Bengtsson authored
The logic for V8 GC normally only takes the external memory growth since last mark-compact into account. Unfortunately, the amount of external memory recorded at the end of MC is often too high. The reason is that it might take a while for the external memory associated with the GCed objects to be released (e.g. V8 itself post a task to release external memory for ArrayBuffer backing stores). In a worst case scenario GC is driven only by external memory and none of the external memory is released by the end of the MC. Then each MC will record the external memory at its highest point and the GC logic will allow the external memory to grow a bit higher each time which can lead to excessive memory use. This patch improves the situation a bit by calculating the growth from the lowest external memory seen since the last MC. That way the growth calculation will be offset from a level presumably closer to the intended one (to what it would have been if the external memory associated with the GCed objects was released during the MC). Now, this fix is not perfect because it can be thrown off by external memory growth occurring before the lingering memory is released. However, it seems to work rather well in practice (e.g. when playing MSE video on YT). Bug: v8:10185 Change-Id: Ifcdd87eb45f3ae4a99d2aeec667c3ae4ca9a52b6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042711Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Peter Marshall authored
> It isn't expensive to set this enum on the isolate and we only call > this in chrome when the ThreadDebugger is enabled anyway. > > This means we have a correct idle state to use with the upcoming > CDP event which emits the thread state. This time, move the dcheck below the stack pointer check. It turns out we call into this with current state == JS, but only when js is on the stack, so we can just move the check lower. Bug: chromium:1025490 Change-Id: Ic9b2eff1ae1880535d0c6da5487ebea4f7e5e62b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2039050Reviewed-by:
-
v8-ci-autoroll-builder authored
Rolling v8/tools/clang: https://chromium.googlesource.com/chromium/src/tools/clang/+log/4f24c2a..7d1284a Rolling v8/tools/luci-go: git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601..git_revision:02ba678a47594da180904851f3e6f809da7e0fc5 Rolling v8/tools/luci-go: git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601..git_revision:02ba678a47594da180904851f3e6f809da7e0fc5 Rolling v8/tools/luci-go: git_revision:bbda6f0d563b25ce0a25b147dec46e5815da5601..git_revision:02ba678a47594da180904851f3e6f809da7e0fc5 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: Iff417ef02e3e79fa094fad500fec3975c915c399 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044840Reviewed-by:
-
- 09 Feb, 2020 4 commits
-
-
Michael Achenbach authored
This reverts commit 31d8ff7a. Reason for revert: https://crbug.com/v8/10190 Original change's description: > [weakrefs] Schedule FinalizationGroup cleanup tasks from within V8 > > Deprecate the following explicit FinalizationGroup APIs in favor of > automatic handling of FinalizationGroup cleanup callbacks: > - v8::Isolate::SetHostCleanupFinalizationGroupCallback > - v8::FinaliationGroup::Cleanup > > If no HostCleanupFinalizationGroupCallback is set, then > FinalizationGroup cleanup callbacks are automatically scheduled by V8 > itself as non-nestable foreground tasks. > > When a Context being disposed, all FinalizationGroups that are > associated with it are removed from the dirty list, cancelling > scheduled cleanup. > > Bug: v8:8179 > Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392 > Commit-Queue: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Cr-Commit-Position: refs/heads/master@{#66184} TBR=ulan@chromium.org,rmcilroy@chromium.org,syg@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:8179 Change-Id: If7869e9a5841803c10e748691f019a7d28f3b62e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043807Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#66190}
-
Johannes Henkel authored
Upstream PR: "Drop && from Serializable::TakeSerialized() &&." https://chromium-review.googlesource.com/c/deps/inspector_protocol/+/2029933 New Rev: 75c465e8d425f2e0b5297245c7eb058411af493a Change-Id: I11dafc589c8f0c5a7e158b9cc5ad5202ba8237e1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2029335Reviewed-by:
Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Johannes Henkel <johannes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66189}
-
Z Nguyen-Huu authored
If both isolates run this test, they are kind of racing on the {tier_down_} flag, hence you get unexpected results. Bug: v8:10189, v8:10099 Change-Id: I8657c32c024898442d5c916cf15077c846276b1f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044544 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: -
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/d34dbf0..8ada491 TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I1a5aaa521f42bf2779605345568ab851d7126e4a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044836Reviewed-by:
-
- 08 Feb, 2020 3 commits
-
-
v8-ci-autoroll-builder authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/68bdecf..d34dbf0 Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapult/+log/8052d29..ea794b8 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/73c7670..3b8094a TBR=machenbach@chromium.org,tmrts@chromium.org Change-Id: I55eddf107dd1001dbcadef4c2222a5bd2b630117 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044833Reviewed-by:
-
Milad Farazmand authored
Change-Id: Id3d6566dc7b8a4cc10574abe79246ebf1398f016 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043024Reviewed-by:
-
Shu-yu Guo authored
Deprecate the following explicit FinalizationGroup APIs in favor of automatic handling of FinalizationGroup cleanup callbacks: - v8::Isolate::SetHostCleanupFinalizationGroupCallback - v8::FinaliationGroup::Cleanup If no HostCleanupFinalizationGroupCallback is set, then FinalizationGroup cleanup callbacks are automatically scheduled by V8 itself as non-nestable foreground tasks. When a Context being disposed, all FinalizationGroups that are associated with it are removed from the dirty list, cancelling scheduled cleanup. Bug: v8:8179 Change-Id: Ic09313a11dd00af36d1f698250b3d735155f45e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1986392 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
- 07 Feb, 2020 12 commits
-
-
Ng Zhi An authored
We lower each op into num_lanes loads, and connecting up the effects in a chain. s64x2 is not implemented since we lowering for 64x2 generally doesn't work anyway. Load extends are a bit more complicated, so we'll do that in a separate change. Bug: v8:9886 Change-Id: I80096827bf8e8e0db1ef0ad1b76759ed1797ca5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031893 Commit-Queue: Zhi An Ng <zhin@chromium.org> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#66183}
-
Seth Brenith authored
This change moves the definition of the bits stored in DebugInfo::flags to Torque, and updates the only Torque usage of that field to use more natural syntax. This is intended as an example of common patterns found in various other classes. Several supporting changes are required: 1. Add a new type representing a bitfield struct stored within a Smi. It is currently called SmiTagged, but I'm open to suggestions. 2. Add an enum-style output for Torque bitfield structs whose bitfields occupy only one bit each. 3. Add a new case to MachineOperatorReducer that makes the generated code for IncBlockCounter match with what was generated before this change. 4. Add support for reporting these bitfields in the postmortem debugging API. The format matches existing bitfields but with an offset value that includes the SMI shift size. Bug: v8:7793 Change-Id: Icaecbe4a162da55d2d9a3a35a8ea85b285b2f1b7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2028832 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66182}
-
Ng Zhi An authored
Bug: v8:10115 Change-Id: If2ef0cd4bef9805dce3c9486d91385d0d40189fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2044650Reviewed-by:
-
Ng Zhi An authored
Mode has an underlying type of int8_t. When printing it we can end up with unprintable ascii values. This shows up with --trace-turbo, and the json file ends up with invalid bytes, and Turbolizer cannot preview. Change-Id: I6bc905416b6e6da35a259734233b366b858452e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2031895Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
-
Bill Ticehurst authored
Change-Id: I47c9211274cefd26bde6bd93aa7503e022df4357 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2042874Reviewed-by:
-
Ng Zhi An authored
These were not added in https://crrev.com/c/2026067 when we added similar tests for other lane sizes, since x64 had a completely different path for i8x16. But this tests are useful anyway for other archs, so add them in. Bug: v8:10115 Change-Id: I77ecca0cd9f4021c94f1538aa5635b5d54983207 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041708Reviewed-by:
-
Ng Zhi An authored
Bug: v8:10039 Change-Id: Ibb0fea59b180d8e015aeee6d6e211ef1f85b0c61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2041698Reviewed-by:
-
Ulan Degenbaev authored
This restores ~4GB limit for 64-bit devices with 16GB physical memory running with pointer compression. Bug: chromium:1049816,chromium:1045034 Change-Id: I7946a4510f8aac2c71fb427776574adba5127cbd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043797 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Etienne Pierre-doray authored
GlobalSize will be used as a hint to schedule scavenger work in https://chromium-review.googlesource.com/c/v8/v8/+/2036661 This is implemented as an atomic variable that's updated when adding/removing segments. Bug: chromium:1012816 Change-Id: I8f6c3f10612f8febda9bfe640d91e235aa3c2f12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043273Reviewed-by:
-
Ulan Degenbaev authored
Now ResourceConstraints::ConfigureDefaults sets the heap limit to 4GB if the physical memory size is greater or equal to 16GB on 64-bit platforms. This CL also adds tests for configuring heap limits from the physical memory size. Bug: chromium:1045034 Change-Id: If0d5a237b2db31309a9a2a6456d950ef70dc71af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043833 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
-
Igor Sheludko authored
Bug: v8:10047 Change-Id: I140fcf453ce7dd6189e0f643f95570163b625456 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043831 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
-
Mythri A authored
We used to optimize functions that are expected to executed only once by not allocating feedback slots for some of the bytecodes. This would help in reducing the memory and avoiding initializing feedback that would be never used. With lazy feedback allocation, we don't allocate feedback vectors for most of such functions anyway. The generated bytecode for oneshot optimized functions is different and if we don't properly track this information we might end up generating different bytecode for the same function. This could causes problems when there is a mismatch between the feedback slots used by the new bytecode and the old bytecode. Since we potentially get most of the benefits of this optimization with lazy feedback vector allocation we can simplify the code by disabling this optimization. Bug: chromium:1045824 Change-Id: Ib94605c8c766adc99f54c8333f780d2448caff5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030918Reviewed-by:
-
