- 22 Aug, 2022 11 commits
-
-
Lu Yahan authored
Port commit aaa15e65 Change-Id: I728d5f786c3e217d249bf6d356b2a004896ed582 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3844663 Auto-Submit: Yahan Lu <yahan@iscas.ac.cn> Reviewed-by:
ji qiu <qiuji@iscas.ac.cn> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#82617}
-
Leszek Swirski authored
This reverts commit 9b0d5cb1. Reason for revert: Seems to fail on gc-stress bots (e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/43472/overview) Original change's description: > [ext-code-space] Fix Code vs non-Code comparisons > > When external code space is enabled comparing Code and non-Code objects > by looking at compressed values is not always correct. Such an approach > works only for comparing Code vs Code objects or non-Code vs non-Code > objects. > > This CL instroduces SLOW_DCHECK into Object comparison operators to > ensure that such a comparison is allowed. Also, this CL instroduces > an Object::SafeEquals() method which compares uncompressed values > and thus is safe to be used for comparing Code with non-Code objects. > > Bug: v8:11880 > Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172 > Reviewed-by: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82611} Bug: v8:11880 Change-Id: Ie34af0135625eff2975f78f4d2901a76b8517eb7 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842930 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#82616}
-
Simon Zünd authored
This CL shuffles around some code in `ScopeIterator` to better reflect the two (internal) iteration modes: - While "inside" the paused function we iterate based on lexical scopes. - Once we move past the paused function we iterate based on runtime contexts. This CL renames the advancing functions to `AdvanceScope` and `AdvanceContext` respectively which operate in the following way: - `AdvanceScope` first checks if the current lexical scope requires a context. If so, we move one context up the chain, since the next lexical scope belongs to that next context. Then we move up one lexical scope. - `AdvanceContext` moves one context up the context chain. Then we we move up through all the lexical scopes until we find the next lexical scope that requires a context. The tricky bit is the transition from scope iteration mode to context iteration mode. This is where the bug fix comes in. After doing one standard `AdvanceScope` from the `closure_scope_` to the next lexical scope, we need to keep moving up through the lexical scope until we find the next lexical scope that requires a context. The CL also changes how we collect the locals blocklist. The locals blocklist is always put on the current context. So every time we move up one context we reset the locals blocklist and every time we move up the lexical scope we collect the scope locals into the blocklist. R=bmeurer@chromium.org, jarin@chromium.org Fixed: chromium:1354464 Change-Id: I7b37687a8827c20d0660a25413d2c9117b5fe5ba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842158 Commit-Queue: Simon Zünd <szuend@chromium.org> Reviewed-by:Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/main@{#82615}
-
Dominik Inführ authored
AdvanceWithDeadline() was only used from AdvanceFromTask(). So we can move this method into AdvanceFromTask(). AdvanceFromTask() and AdvanceOnAllocation() share quite some code, there is already a common bottleneck for both methods: Step(). So we can move that code into Step(). Bug: v8:12775 Change-Id: I0f749f52df05d951f4310f05ff0d3977c6b2a9aa Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843143 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#82614}
-
Al Muthanna Athamina authored
Bug: v8:13052 Change-Id: I97c8d44dfd54d2a1352ceed7675d019bdec33396 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3822863Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Almothana Athamneh <almuthanna@chromium.org> Reviewed-by:
Liviu Rau <liviurau@google.com> Cr-Commit-Position: refs/heads/main@{#82613}
-
Darius M authored
The generational write-barrier currently does not support background threads. As a result, building in the background a ConsString that points to a young string can lead to bugs, since the young string could be freed. Bug: v8:13203 Change-Id: I0df7c8cca8712d765eff0b1e918379f5477fdee5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840940Reviewed-by:
-
ishell@chromium.org authored
When external code space is enabled comparing Code and non-Code objects by looking at compressed values is not always correct. Such an approach works only for comparing Code vs Code objects or non-Code vs non-Code objects. This CL instroduces SLOW_DCHECK into Object comparison operators to ensure that such a comparison is allowed. Also, this CL instroduces an Object::SafeEquals() method which compares uncompressed values and thus is safe to be used for comparing Code with non-Code objects. Bug: v8:11880 Change-Id: I7ccf1f90f927beb2bb9f45efb303e902b1838d02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838172Reviewed-by:
Jakob Linke <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#82611}
-
jameslahm authored
...to clear the recompilable code. Bug: v8:13181 Change-Id: I6b78bbd2f08242fdd4659113ce1b4fa81174f8a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829243Reviewed-by:
-
Dominik Inführ authored
Write barrier was only used in Factory::CopyCode for the InterpreterEntryTrampolineForProfiling. This was removed in in https://crrev.com/c/3811287. Change-Id: I4cd0863fc2629d2d564af6a269e722d1a9e128f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843141 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
-
Omer Katz authored
Bug: v8:13185 Change-Id: Id145e76ad52469d9aa8a12c9172851b086421afd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840217 Commit-Queue: Omer Katz <omerkatz@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
-
Shu-yu Guo authored
Turns out parking the outer Isolate needs to encompass the entire lifetime of the inner Isolate during snapshot stress. Isolate initialization locks the shared Isolate's client mutex to prevent shared GCs. This mutex is also taken on Heap teardown on Isolate shutdown during the shared heap verification, which may end up waiting in a safepoint, causing deadlock. Bug: v8:13217 Change-Id: I3893ae883ab345a9d36c9437ea15e90f18951057 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843288Reviewed-by:
-
- 21 Aug, 2022 1 commit
-
-
Feng Yu authored
Bug: v8:12781 Change-Id: I0271c632a057ed457af5af59cb918d86472563d8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3827131 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#82606}
-
- 20 Aug, 2022 2 commits
-
-
Milad Fa authored
Change-Id: I28747c49422280a7fd02ce771bd4f7c6ec60002c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840820 Commit-Queue: Milad Farazmand <mfarazma@redhat.com> Reviewed-by:
Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/main@{#82605}
-
Milad Fa authored
Change-Id: I5da6270dc5c3d9b561eeb6c6dd3a938e705039c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3843088Reviewed-by:
-
- 19 Aug, 2022 26 commits
-
-
Shu-yu Guo authored
This reverts commit abd0adf1. Reason for revert: Test times out on Win64 https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/23024/overview Original change's description: > [compiler] Make ReduceWord32EqualForConstantRhs work for Word64Equal > > Adds reduction case in MachineOperatorReducer for when the left-hand side of a > Word64Equals is based on a 64-bit shift-and-mask operation, as is the case > when Torque accesses 64-bit bitfields. > > This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with > React-Redux being improved by 0.4%. > > Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027 > Commit-Queue: George Wort <george.wort@arm.com> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82593} Change-Id: I26515348a3d8de58445ecddc0486d9fcc2711cec No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3839048 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Shu-yu Guo <syg@chromium.org> Owners-Override: Shu-yu Guo <syg@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82603}
-
Clemens Backes authored
The mutex is there to protect against concurrent compilation of the same function. It can be avoided by accumulating the vector of call targets locally in the LiftoffCompiler, and only transferring it to the stored type feedback once at the end (under the mutex). Also, choose slightly better data structures: base::OwnedVector uses less memory that std::vector (because it never over-reserves), and std::unordered_map is more memory efficient and faster to lookup that {std::map}. R=jkummerow@chromium.org Bug: v8:13209 Change-Id: I7aa82560a83cbac5c019effc7fd38c9b1495a42c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840294 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#82602}
-
Shu-yu Guo authored
WaiterQueueNodes as used by JS synchronization primitives are per-main thread, and external pointer handles to those nodes are 1-1. That 1-1-ness is captured by each main thread Isolate having a waiter_queue_node_external_pointer_ field. The current logic is incorrect on unlock paths as the Isolate that requested the unlock can point its own waiter_queue_node_external_pointer_ to another Isolate's WaiterQueueNode. This CL fixes this by having each WaiterQueueNode hold onto its own external pointer handle. This CL also fixes an embarrassing bug where the WaiterQueueNode was not correctly dequeued on timeout. Bug: v8:13189, v8:12547 Change-Id: I8db16ae6d653d2e71989ad003faae20fcee06a25 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832298 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#82601}
-
Nico Hartmann authored
Rolling v8/build: https://chromium.googlesource.com/chromium/src/build/+log/339f8c6..8291582 Rolling v8/buildtools: https://chromium.googlesource.com/chromium/src/buildtools/+log/3d64821..3a4c850 Rolling v8/buildtools/third_party/libc++/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxx/+log/6cc58d6..db72216 Rolling v8/buildtools/third_party/libc++abi/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libcxxab/+log/039323b..d2e4dc7 Rolling v8/buildtools/third_party/libunwind/trunk: https://chromium.googlesource.com/external/github.com/llvm/llvm-project/libunwind/+log/030b4eb..f87795e Rolling v8/third_party/catapult: https://chromium.googlesource.com/catapul/+log/b342107..7294631 Rolling v8/third_party/depot_tools: https://chromium.googlesource.com/chromium/tools/depot_tools/+log/268d645..44b7330 Rolling v8/third_party/fuchsia-sdk/sdk: version:9.20220812.1.1..version:9.20220819.1.1 R=v8-waterfall-sheriff@grotations.appspotmail.com,mtv-sf-v8-sheriff@grotations.appspotmail.com Change-Id: I9fb7df0fc77ec27a1a8ea69eef080e095c22edf7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842152 Commit-Queue: Shu-yu Guo <syg@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#82600}
-
Shu-yu Guo authored
Bug: v8:12548 Change-Id: Ib0b22cd941f0ab928c9c3d31d77695972d87c137 No-try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840817Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#82599}
-
Deepti Gandluri authored
Bug: v8:12609, v8:12284 Change-Id: I2b72b20b64d3487343212f30fba614a92845e770 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837854 Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#82598}
-
Shu-yu Guo authored
Otherwise allocated external pointer handles may be swept if never set by the caller. Bug: v8:10391 Change-Id: I3d727b80635ac8e21bd403de6bcad59091ed80a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3832528Reviewed-by:
-
Shu-yu Guo authored
Currently there is nothing ensuring the internal VM state of shared objects are in a coherent state and visible to other threads when the shared object is published. This CL adds a store-store memory barrier when returning from Factory methods that allocate shared JSObjects that are exposed to user JS code. For primitives, there is an additional store-store memory barrier in the shared value barrier. Bug: v8:12547 Change-Id: I4833c7ebf02cc352da9b006d2732669d6d043172 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng,v8_linux64_tsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3819041 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
-
Leon Bettscheider authored
This CL makes concurrent MinorMC only bailout on the write barrier if the value is not in young generation. Bug: v8:13012 Change-Id: I941c6f1e676440cf69e1d4fefcf2786383c9f678 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840296 Commit-Queue: Leon Bettscheider <bettscheider@google.com> Reviewed-by:
-
Al Muthanna Athamina authored
Bug: v8:13206 Change-Id: I27cd34a77e15e812881a57e7e5538a0e31b34315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837861Reviewed-by:
-
George Wort authored
Adds reduction case in MachineOperatorReducer for when the left-hand side of a Word64Equals is based on a 64-bit shift-and-mask operation, as is the case when Torque accesses 64-bit bitfields. This improves Speedometer2 by 0.15% on a Neoverse-N1 machine, with React-Redux being improved by 0.4%. Change-Id: Icd0451c00c1b25f7d370e81bddcfd668a5b2523c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3834027 Commit-Queue: George Wort <george.wort@arm.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#82593}
-
Darius M authored
Before https://crrev.com/c/3829541, ReduceStringPrototypeStartsWith would not be called if the String's content wasn't safe to access in the background, because StringRef::length would fail in that case. Now that StringRef::length always succeeds, an additional check is required before calling ReduceStringPrototypeStartsWith. Note that none of the other callers of StringRef::length access the String's content later, so we shouldn't have any more bugs caused by the aforementioned CL. Bug: chromium:1354439 Change-Id: I4a590ccdb7cc4c8a85e4e6beaf6f3c3ab2d7d479 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840938 Commit-Queue: Darius Mercadier <dmercadier@chromium.org> Reviewed-by:
-
Clemens Backes authored
While working through the type feedback implementation, I left some documentation and fixed some oddities or inconsistencies. R=jkummerow@chromium.org Bug: v8:13209 Change-Id: I6ba9b77ecf30ae020a57f77435005a1a57c2fc7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840293Reviewed-by:
-
Leon Bettscheider authored
This CL bails out on the generated code write barrier when minor incremental marking is active. Currently is_minor_marking_flag_ is always false. It will be connected with incremental marking in subsequent CLs. Bug: v8:13012 Change-Id: I0f5bc4aa14e9d56adbdad305499f2ca8f951765b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838784Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#82590}
-
Liu Yu authored
Bug: v8:12887 Change-Id: I467335899d8f4d72f256843d5922703d3ba1f976 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840936 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
-
Clemens Backes authored
This reverts commit b3a27f22. Reason for revert: Fails 'debug-enabled-tier-down-wasm' flakily (https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64/48026/overview) Original change's description: > Reland "[wasm] Refactor compilation tier computations" > > This is a reland of commit e50472d6. > In {ApplyCompilationHintToInitialProgress} we would reset the baseline > tier to {kNone} if the compilation strategy is {kDefault}, which is > wrong. We would not generate code but also not install the lazy stub, > so whenever we start executing the code before top-tier is ready we > would crash. > > Original change's description: > > [wasm] Refactor compilation tier computations > > > > The way we initialized the "compilation progress" was pretty convoluted, > > with multiple levels of functions being called for initializing every > > single slot. > > > > This CL refactors this to compute one default value for the whole > > module, and only modifies those slots that need special handling (e.g. > > because of compilation hints, or lazy/eager compilation after > > deserialization). > > > > We also rename "liftoff_functions" to "eager_functions" in the > > deserialization path; the idea is that those functions should get > > eagerly compiled because we expect them to be needed during execution. > > Usually they would be Liftoff-compiled, but it's more consistent to use > > the existing logic to choose the baseline tier. In the default > > configuration, this will still use Liftoff, but if Liftoff is disabled > > we will use TurboFan instead. > > > > R=jkummerow@chromium.org, ahaas@chromium.org > > > > Bug: v8:12425 > > Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606 > > Commit-Queue: Clemens Backes <clemensb@chromium.org> > > Reviewed-by: Andreas Haas <ahaas@chromium.org> > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#82521} > > Bug: v8:12425 > Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82585} Bug: v8:12425 Change-Id: Ic86d3f5b0e0603dae62ccead3be052d928209506 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3842208 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Clemens Backes <clemensb@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82588}
-
Samuel Groß authored
Now that V8_SANDBOXED_POINTERS is enabled by default on every platform if the sandbox is enabled, it is no longer necessary to have a separate option to enable/disable sandboxed pointers. Bug: chromium:1218005 Change-Id: I2ab4c7c758010007765a3b0595357ddecfe9f258 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840937Reviewed-by:
-
Anton Bikineev authored
Since the overall motionmark regression is minor (<0.5%), we decided to get benefits of pointer compression on M1. The CL can also slightly regress speedometer2 (~0.3%). Bug: chromium:1325007 Change-Id: Ib278f0e82e0ebde563caac79b9f32edfe2d09a53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840301 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
-
Clemens Backes authored
This is a reland of commit e50472d6. In {ApplyCompilationHintToInitialProgress} we would reset the baseline tier to {kNone} if the compilation strategy is {kDefault}, which is wrong. We would not generate code but also not install the lazy stub, so whenever we start executing the code before top-tier is ready we would crash. Original change's description: > [wasm] Refactor compilation tier computations > > The way we initialized the "compilation progress" was pretty convoluted, > with multiple levels of functions being called for initializing every > single slot. > > This CL refactors this to compute one default value for the whole > module, and only modifies those slots that need special handling (e.g. > because of compilation hints, or lazy/eager compilation after > deserialization). > > We also rename "liftoff_functions" to "eager_functions" in the > deserialization path; the idea is that those functions should get > eagerly compiled because we expect them to be needed during execution. > Usually they would be Liftoff-compiled, but it's more consistent to use > the existing logic to choose the baseline tier. In the default > configuration, this will still use Liftoff, but if Liftoff is disabled > we will use TurboFan instead. > > R=jkummerow@chromium.org, ahaas@chromium.org > > Bug: v8:12425 > Change-Id: Ie58840b19efd0b1e98f1b02d5f1d4369410ed8e1 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3829606 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82521} Bug: v8:12425 Change-Id: Ie41e63148bf6bd0e38fc07a3a514f1094d9d26cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3838409Reviewed-by:
-
Anton Bikineev authored
NormalPageMemoryRegion is a span of 10 pages, all of which must belong to the same space. This requirement imposes a fragmentation issue for virtual space, which is not ideal for the current 2GB cage configuration. The CL fixes this by mixing pages of different spaces inside the same NormalPageMemoryRegion. With cage it's actually not necessary anymore to have NormalPageMemoryRegion, but we keep it to allow the code to be uniform for cage/non-cage configurations. There is no type confusion across spaces, since pages (even empty) are never shared between spaces. In addition, the shared cage puts an additional memory constraint on the GC. So, there is no security benefit in having NormalPageMemoryRegion assigned to a single space. Savings in reserved address space: cnn:2021: 14% facebook_infinite_scroll:2018: 23% Bug: chromium:1325007, chromium:1352649 Change-Id: I7b49032d581dd56feb8633734a1f37803e9526c6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840749Reviewed-by:
-
Samuel Groß authored
The function is no longer used in Chromium or V8 and can therefore be deleted. This CL also simplifies V8::GetSandboxSizeInBytes, which now no longer needs to be able to deal with an uninitialized sandbox. Bug: v8:10391 Change-Id: I22d6b0e03de1fd2ba3d38c4e476fca44068b62f9 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3769690Reviewed-by:
-
Michael Lippautz authored
Bug: v8:13089 Change-Id: Ic1c5a596adb822494aff490e04bd23cf84fb53f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3840295 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#82582}
-
Dominik Inführ authored
This CL removes the COMPLETE state from incremental marking. Since then the only states left were STOPPED and MARKING, we can replace the state with an is_running_ boolean field. The state could change back-and-forth between MARKING and COMPLETE. IsMarking() was already also checking for COMPLETE. So most code already treated both states the same. IsComplete() now checks whether marking is running and a transitive closure was reached already. IncrementalMarking::Step() didn't process the marking queue when in COMPLETE. This should be relatively rare though since it only transitioned into COMPLETE when the stack guard was armed and the allocation observer ran again before reaching a stack guard check. Bug: v8:12775 Change-Id: Ied48d8c512ad3d1b3d2e29393d43b434b5fda8fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3835689Reviewed-by:
-
Nico Hartmann authored
This reverts commit c3a5c5b1. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20shared/21941/overview Original change's description: > [heap] Ensure all old-to-shared slots are recorded > > This CL adds verification of the old-to-shared remembered set to > --verify-heap. During shared GCs client heaps will be scanned for > references into the shared heap, this CL will CHECK that every found > slot is contained in the old-to-shared remembered set. After this > gets a bit more stable, the full heap iteration can be dropped and we > can fully rely on the remembered set instead. > > Bug: v8:11708 > Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#82578} Bug: v8:11708 Change-Id: I26553d3b06d0e257a3425eeb884ccce57f026bde No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3841567 Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#82580}
-
Qifan Pan authored
`JSWasmCallData` is replaced with a flag `do_conversion` to indicate if conversions of arguments and returns are needed, which is set as false for inlined js-to-wasm call wrappers. Bug: v8:9407 Change-Id: I35244c8fc13d464d48031fb9d7d04ab277646ec5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3837858Reviewed-by:
-
Dominik Inführ authored
This CL adds verification of the old-to-shared remembered set to --verify-heap. During shared GCs client heaps will be scanned for references into the shared heap, this CL will CHECK that every found slot is contained in the old-to-shared remembered set. After this gets a bit more stable, the full heap iteration can be dropped and we can fully rely on the remembered set instead. Bug: v8:11708 Change-Id: I0b5c4edfe3271306e4e7af7394472534113e1953 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3792605Reviewed-by:
-
