- 12 Aug, 2020 12 commits
-
-
Santiago Aboy Solanes authored
The (now unique)PersistentHandles container follows this path: 1) PersistentHandles created via PersistentHandlesScope inside of CompilationHandleScope 2) Owned by OptimizedCompilationInfo 3) Owned by JSHeapBroker 4) Owned by the broker's LocalHeap 5) Back to the broker for a brief moment (after tearing down the LocalHeap as part of exiting LocalHeapScope) 6) Back to OptimizedCompilationInfo when exiting the LocalHeapScope. There is a special case in GenerateCodeForTesting where the JSHeapBroker will not be retired in that same method. In this case, we need to re-attach the PersistentHandles container to the JSHeapBroker. The identity map of the persistent & canonical handles also gets passed around like the persistent handles. The only difference is that is created in the CanonicalHandleScope (i.e step 1) is different). Bug: v8:7790 Change-Id: I2da77a7e08f3fd360a46b606c5fbda08c0af27df Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2332811 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69360}
-
Thibaud Michaud authored
Remove extra source positions added by Liftoff to help with OSR. Compute the return address based on the call source position instead. R=clemensb@chromium.org Bug: v8:10337 Change-Id: Ifc14e924825b670ebaed920bb19d0fa09eca1b23 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351666Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69359}
-
Zeynep Cankara authored
This CL maximises the space use in between panels and fixes asymmetries in the Web app to make the UI panel views more compact and increase accessibility of the web app for different screen size. Bug: v8:10644 Change-Id: I07bf6317db2cf3fa59204120276f0f885e356e6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351660Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Zeynep Cankara <zcankara@google.com> Cr-Commit-Position: refs/heads/master@{#69358}
-
Sathya Gunasekaran authored
FeedbackSlotIterator abstracts over the different IC states and provides an unified interface to iterate over the map and handlers in the IC. Bug: v8:10582 Change-Id: I67861bfbd33d82e8b1ad06156fbf6fd72775321c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349295 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69357}
-
Dominik Inführ authored
Move external memory counters out of IsolateData back into Heap. The class ExternalMemoryAccounting now stores all counters and is responsible for updates. This change will allow turning counters into atomic variables. Bug: v8:10315 Change-Id: I2abeda298d3cfcc630fd04ca78a3d6d703e3b419 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346647Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69356}
-
Thibaud Michaud authored
DebugInfo::RemoveBreakpoint was never called. Call it in WasmScript::ClearBreakPoint to remove the breakpoint from the list and recompile the function. R=clemensb@chromium.org Bug: v8:10147 Change-Id: I0d11bdab102eeacc2a5f9ae9b4a20e8c900b26f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351665Reviewed-by: Clemens Backes <clemensb@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69355}
-
Dominik Inführ authored
The only user was ArrayBufferTracker which got removed already. Bug: v8:10064 Change-Id: I97f8ed0727abec01b3b65ba965026f61fb9acb85 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346406 Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69354}
-
Leszek Swirski authored
Since the StringTable can only contain old strings, skip iterating it when SkipRoot::kOldGeneration is set. Bug: chromium:1115132, chromium:1115100 Change-Id: I6d065a0ea7f3142c5d474eb0919e801e13976f6c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2351664 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69353}
-
Clemens Backes authored
A minor fix to the {InterpretAndExecuteModule} function: We instantiate the module twice. If the first instantiation worked, then also the second instantiation must succeed. Plus minor drive-by cleanup. R=ahaas@chromium.org Bug: chromium:1113681 Change-Id: Ib897cb1907152cdd9b0ed2b513a6c8217a3f400c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349288 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69352}
-
Dominik Inführ authored
ArrayBufferTracker was superseded by ArrayBufferList and ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production, we can remove the unused ArrayBufferTracker mechanism. Bug: v8:10064 Change-Id: I479169c76b6c5c634672024f77e689bb64a36504 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69351}
-
Santiago Aboy Solanes authored
Also remove the unused StoreFixedDoubleArrayHoleSmi Bug: v8:9708, v8:6949 Change-Id: I07b6e83520a6ac667a4bd08d90510931141719a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349303Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69350}
-
Santiago Aboy Solanes authored
Bug: v8:9708, v8:6949 Change-Id: I3fa0b3d76fb6343eb986321e40cee673b6c30670 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349302Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69349}
-
- 11 Aug, 2020 28 commits
-
-
Sathya Gunasekaran authored
Bug: v8:10582, v8:9684 Change-Id: I4b53b161f9154212568856206ff011e61975e431 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2247652 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69348}
-
Bill Budge authored
This reverts commit f4548e75. Reason for revert: Breaks some gap resolver tests: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/24204 Original change's description: > [regalloc] Place spill instructions optimally > > Design doc: > https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing > > Most of this change follows directly what is discussed in the design > document. A few other things are also changed: > > - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so > that it can make use of the decision regarding whether a value is > spilled at its definition or later. > - SpillSlotLocator is removed. It was already somewhat confusing, > because the responsibility for marking blocks as needing frames was > split: in some cases they were marked by SpillSlotLocator, and in > other cases they were marked by CommitSpillsInDeferredBlocks. With > this change, that split responsibility would become yet more > confusing if we kept SpillSlotLocator for the values that are spilled > at their definition, so I propose a simpler rule that whatever code > adds the spill move also marks the block. > - A few class definitions (LiveRangeBound, FindResult, > LiveRangeBoundArray, and LiveRangeFinder) are moved without > modification from register-allocator.cc to register-allocator.h so > that we can refer to them from another cc file. > > Bug: v8:10606 > Change-Id: I374a3219a5de477a53bc48117e230287eae89e72 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390 > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69345} TBR=rmcilroy@chromium.org,seth.brenith@microsoft.com,thibaudm@chromium.org Change-Id: Ie57109a009ee7ee541a6ff6f89901d1ac99027d2 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10606 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2350440Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#69347}
-
Ng Zhi An authored
This is a reland of 57242a05 no-sse4.1 builds were failing due to missing simd-scalar-lowering for s128.const, this reland adds that implementation. Original change's description: > [wasm-simd][arm] Use vmov to move all ones to register > > vceq(dst, dst, dst) does not seem to always set the register to all > ones. The right way should be be to use vmov (immediate) anyway. This > was not supported in the assembler yet, so we need changes to the > assembler, diassembler, and simulator. > > There is an unfortunate fork in logic in the simulator, due to the way > the switches are set up, vmov (imm) logic is duplicated across two > different cases, because the switch looks at the top bit of the > immediate. Refactoring this will be a bigger change that is irrelevant > for this bug, so I'm putting that off for now. Instead we extract the > core of vmov (imm) into helpers and call it in the two cases. > > Bug: chromium:1112124 > Change-Id: I283dbcd86cb0572e5ee720835f897b51fae96701 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2337503 > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Bill Budge <bbudge@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69315} Bug: chromium:1112124 Change-Id: Id450e5cea41f7a569e49be8386a7788ca8f00658 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346937Reviewed-by: Bill Budge <bbudge@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#69346}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1n9ADWnDI-sw0OvdSmrthf61prmDqbDmQq-NSrQw2MVI/edit?usp=sharing Most of this change follows directly what is discussed in the design document. A few other things are also changed: - PopulateReferenceMapsPhase is moved after ResolveControlFlowPhase so that it can make use of the decision regarding whether a value is spilled at its definition or later. - SpillSlotLocator is removed. It was already somewhat confusing, because the responsibility for marking blocks as needing frames was split: in some cases they were marked by SpillSlotLocator, and in other cases they were marked by CommitSpillsInDeferredBlocks. With this change, that split responsibility would become yet more confusing if we kept SpillSlotLocator for the values that are spilled at their definition, so I propose a simpler rule that whatever code adds the spill move also marks the block. - A few class definitions (LiveRangeBound, FindResult, LiveRangeBoundArray, and LiveRangeFinder) are moved without modification from register-allocator.cc to register-allocator.h so that we can refer to them from another cc file. Bug: v8:10606 Change-Id: I374a3219a5de477a53bc48117e230287eae89e72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2285390 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/master@{#69345}
-
Seth Brenith authored
I noticed a pattern that has been copied around to various places and thought a helper function might be appropriate. Change-Id: I8944ac5166c649f15c09f587308406cab317b8d4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346766Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#69344}
-
Milad Farazmand authored
Change-Id: Ie3e14a6ef4531349e81a8ae741bc7470c7e547ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349468Reviewed-by: Junliang Yan <jyan@ca.ibm.com> Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com> Cr-Commit-Position: refs/heads/master@{#69343}
-
Santiago Aboy Solanes authored
Also remove ParameterMode Bug: v8:9708, v8:6949 Change-Id: Iaf51004472a4aef0acf29d01497b1047247dc83d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349301Reviewed-by: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#69342}
-
Bill Budge authored
This reverts commit 0ba115e6. Reason for revert: Breaks test on TSAN - block-conflicts https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN%20-%20concurrent%20marking/14230 Original change's description: > Reland^2 "[flags] warn about contradictory flags" > > This is a reland of d8f8a7e2 > Change compared to last reland: > - Do not check for d8 flag contradictions in the presence of --fuzzing > - Allow identical re-declaration of --cache=* > > Original change's description: > > Reland "[flags] warn about contradictory flags" > > > > This is a reland of b8f91666 > > Difference to previous CL: Additional functionality to specify > > incompatible flags based on GN variables and extra-flags, used > > to fix the issues that came up on the waterfall. > > > > This also changes the rules regarding repeated flags: While > > explicitly repeated flags are allowed for boolean values as long > > as they are identical, repeated flags or explicit flags in the > > presence of an active implication are disallowed for non-boolean > > flags. The latter simplifies specifying conflict rules in > > variants.py. Otherwise a rule like > > > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = { > > "--gc-interval=*": ["--gc-interval=*"], > > } > > > > wouldn't work because specifying the same GC interval twice > > wouldn't actually count as a conflict. This was an issue with > > test/mjsunit/wasm/gc-buffer.js, which specifies > > --gc-interval=500 exactly like the extra flag by the stress bot. > > > > Also, this now expands contradictory flags checking to d8 flags > > for consistency. > > > > Original change's description: > > > [flags] warn about contradictory flags > > > > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/ > > > > > > Bug: v8:10577 > > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792 > > > Reviewed-by: Clemens Backes <clemensb@chromium.org> > > > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > > > Reviewed-by: Georg Neis <neis@chromium.org> > > > Reviewed-by: Tamer Tas <tmrts@chromium.org> > > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > > Cr-Commit-Position: refs/heads/master@{#68168} > > > > Bug: v8:10577 > > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115 > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Reviewed-by: Tamer Tas <tmrts@chromium.org> > > Reviewed-by: Clemens Backes <clemensb@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#68989} > > Bug: v8:10577 > Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69339} TBR=machenbach@chromium.org,neis@chromium.org,clemensb@chromium.org,tebbi@chromium.org,tmrts@chromium.org Change-Id: I1454a05e357ddd704db7fb79e51be65d45a9a16e No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10577 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2348365Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#69341}
-
Andreas Haas authored
R=neis@chromium.org Bug: v8:10506 Change-Id: I4cffa301fd306acc4da4375bc6f0729d363cc659 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349307Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69340}
-
Tobias Tebbi authored
This is a reland of d8f8a7e2 Change compared to last reland: - Do not check for d8 flag contradictions in the presence of --fuzzing - Allow identical re-declaration of --cache=* Original change's description: > Reland "[flags] warn about contradictory flags" > > This is a reland of b8f91666 > Difference to previous CL: Additional functionality to specify > incompatible flags based on GN variables and extra-flags, used > to fix the issues that came up on the waterfall. > > This also changes the rules regarding repeated flags: While > explicitly repeated flags are allowed for boolean values as long > as they are identical, repeated flags or explicit flags in the > presence of an active implication are disallowed for non-boolean > flags. The latter simplifies specifying conflict rules in > variants.py. Otherwise a rule like > > INCOMPATIBLE_FLAGS_PER_EXTRA_FLAG = { > "--gc-interval=*": ["--gc-interval=*"], > } > > wouldn't work because specifying the same GC interval twice > wouldn't actually count as a conflict. This was an issue with > test/mjsunit/wasm/gc-buffer.js, which specifies > --gc-interval=500 exactly like the extra flag by the stress bot. > > Also, this now expands contradictory flags checking to d8 flags > for consistency. > > Original change's description: > > [flags] warn about contradictory flags > > > > Design Doc: https://docs.google.com/document/d/1lkvu8crkK7Ei39qjkPCFijpNyxWXsOktG9GB-7K34jM/ > > > > Bug: v8:10577 > > Change-Id: Ib9cfdffa401c48c895bf31caed5ee03545beddab > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2154792 > > Reviewed-by: Clemens Backes <clemensb@chromium.org> > > Reviewed-by: Michael Achenbach <machenbach@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Tamer Tas <tmrts@chromium.org> > > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#68168} > > Bug: v8:10577 > Change-Id: I268e590ee18a535b13dee14eeb15ddd0a9ee8341 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2235115 > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Reviewed-by: Tamer Tas <tmrts@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#68989} Bug: v8:10577 Change-Id: I31d2794d4f9ff630f3444210100c64d67d881276 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339464 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69339}
-
Mythri A authored
We shouldn't spill weak pointers onto the stack when calling functions that can trigger GC. DynamicMapChecks operator was using feedback loaded from the feedback vector across the TryMigrateInstance function call. The feedback can be a weak pointer to receiver map for monomorphic cases and TryMigrateInstance can trigger a GC. This cl fixes it by holding a holding a strong reference to the feedback. Bug: v8:10774,v8:10582,v8:9684 Change-Id: Ia36f4d8ad46421ae570f41439bc1f0875081deee Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336804Reviewed-by: Georg Neis <neis@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#69338}
-
Dominik Inführ authored
Isolate::GetHeapStatistics uses PagedSpace::Available, which races with allocating background threads. Bug: v8:10315 Change-Id: I6e0dc37d90e0c7a3e3dd2b8bdb77f2ea82372c13 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349294Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69337}
-
Dominik Inführ authored
SimulateIncrementalMarking needs to invoke EnsureSweepingCompleted in a safepoint. Otherwise RefillFreeList in this method races with concurrent allocation. Bug: v8:10315 Change-Id: I9aa11d225a1c1844648788f956fd72988fe269fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349299Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69336}
-
Clemens Backes authored
This is a reland of 60ee70bb. The wasm c-api flakes were fixed in https://crrev.com/c/2349293. Original change's description: > [wasm] Ensure that only TurboFan code is serialized > > We have the implicit assumption that Liftoff code will never be > serialized, and we start relying on that when implementing new features > (debugging, dynamic tiering). > > This CL makes the serializer fail if the module contains any Liftoff > code. Existing tests are changed to ensure that we fully tiered up > before serializing a module (similar to the logic in Chromium). > The "wasm-clone-module" test needs to serialize the module before > enabling the debugger. > > Note that chrome currently only serializes a module after it fully > tiered up, so that should be fine. If other embedders need the ability > to serialize a module in an arbitrary state, we will have to fix this > later. With this CL we will be on the safe side though and (gracefully) > fail serialization instead of accidentally serializing Liftoff code. > > R=ahaas@chromium.org > > Bug: v8:10777 > Change-Id: I1245e5f7fda3447a544c1e3525e1239cde759174 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336799 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Andreas Haas <ahaas@chromium.org> > Cr-Commit-Position: refs/heads/master@{#69276} Bug: v8:10777 Change-Id: I2a7c1429812ca46d88a2902b8e0a7b7e3d638b56 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349290Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69335}
-
Dominik Inführ authored
Now that background threads participate in sweeping, this method races because multiple threads now want to update that counter. We could either make this counter atomic or remove it entirely. This CL removes this counter since it isn't strictly necessary, it is only used when sweeper finds more garbage than markers. This happens e.g. with right-trimming but should be rare and is eventually fixed in the next GC. Bug: v8:10315 Change-Id: Iebae8937860160a3b49bedd03c2e21e41f7dfe76 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349296Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69334}
-
Zeynep Cankara authored
This CL checks the version of the log file by checking the format of Map Objects processed by the IC processor. The version check requirement came from the modified IC event logging pipeline of the V8. Bug: v8:10644 Change-Id: Ic661a34cfaf15edfde5fa24588275ac055a5bb5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343067 Commit-Queue: Zeynep Cankara <zcankara@google.com> Reviewed-by: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#69333}
-
Clemens Backes authored
We only want to serialize TurboFan code, because Liftoff code could contain breakpoints, and we start thinking about embedding other non-relocatable constants. Thus, wait until top-tier compilation finished before triggering serialization. A follow-up CL will make serialization fail if any Liftoff code is encountered. R=ahaas@chromium.org Bug: v8:10777 Change-Id: I73d6c2d868545fcd4069a8cf9850ca7fca375ecb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2349293Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69332}
-
Clemens Backes authored
This removes the {InterpretWasmModuleForTesting} function in favor of {InterpretWasmModule}, and uses that in {InterpretAndExecuteModule}. The latter again is reused in {WasmExecutionFuzzer::FuzzWasmModule}, such that all fuzzers execute the same checks now. R=ahaas@chromium.org Bug: chromium:1112099, chromium:1113681 Change-Id: Ia8818b93e9274266a81573edd6852e4e4734b150 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346283 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69331}
-
Ulan Degenbaev authored
This is the first step in refactoring Worklist to allow arbitrary number of local worklists with private segments: - Introduce MarkingWorklistImpl<> which will eventually replace (and will be renamed to) Worklist. - MarkingWorklistImpl<> owns the global pool of segments but does not keep track of private segments. - MarkingWorklistImpl<>::Local owns private segments and can be constructed dynamically on background threads. - Rename the existing MarkingWorklistsHolder to MarkingWorklists. - Rename the existing MarkingWorklists to MarkingWorklists::Local. - Rename the existing marking_workists_holder to marking_worklists. - Rename the existing marking_worklists to local_marking_worklists. Design doc: https://bit.ly/2XMtjLi Bug: v8:10315 Change-Id: I9da34883ad34f4572fccd40c51e51eaf50c617bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2343330Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69330}
-
Kim-Anh Tran authored
This change adds support for skipping locations that are in a skipList on step over. This feature is useful for when we are debugging C++ applications that have DWARF information we only want to stop on every breakable location in C++, not non every breakable location on wasm level. Bug: chromium:1105765 Change-Id: Ie835b011a00cf31e0c5b2df1ac96ebd89f53d23a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339458Reviewed-by: Eric Leese <leese@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Commit-Queue: Kim-Anh Tran <kimanh@chromium.org> Cr-Commit-Position: refs/heads/master@{#69329}
-
evih authored
Simplify by using assembler function. Bug: v8:10701 Change-Id: I7d07a271369fcf8ad34652b6e94463b0468ee1c5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346282 Commit-Queue: Eva Herencsárová <evih@google.com> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69328}
-
Clemens Backes authored
Remove the {ErrorThrower} parameter to {CallWasmFunctionForTesting} (it was only populated in a subset of failures anyway), and merge it with {RunWasmModuleForTesting}. R=ahaas@chromium.org Bug: chromium:1113681 Change-Id: I5391e2f911928641a907bc5dad5a54677c90acb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346279Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69327}
-
Jakob Gruber authored
Updated: IsOptimized -> HasAttachedOptimizedCode HasOptimizedCode -> HasAvailableOptimizedCode IsInterpreted -> ActiveTierIsIgnition Bug: v8:8888 Change-Id: I96363622b67b53371a974f1c17cef387093f053c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346404 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69326}
-
Jakob Gruber authored
This CL adds more systematic predicates to JSFunction to reason about available code kinds. Introduced terminology: - Attached code kinds are accessible directly from the JSFunction itself. - Available code kinds are either attached or accessible indirectly. - The Active code kind is the one that would be executed on the next function execution. Bug: v8:8888 Change-Id: I9468884dfe97a6cb73f8329b2b6cb62b622d3e7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2345966 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#69325}
-
Clemens Backes authored
The "wasm fuzzer" and "wasm async fuzzer" use the {InterpretAndExecuteModule} function, which did not check for possible nondeterminism in the interpreter yet. This can lead to wrong reports of mismatches, or in endless loops being executed in compiled code which was not executed in the interpreter. This CL adds the check for nondeterminism in that function, and adds a TODO to merge the two very similar methods. R=ahaas@chromium.org Bug: chromium:1112099, chromium:1113681 Change-Id: I80b01d4c53d04f0632807fa852147dc9fb8075ca Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346280 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#69324}
-
Clemens Backes authored
The interpreter is used for testing (including fuzzing) only, and in these cases it's often important to see the exact value of a float. Both decimal and scientific notation does not show the full value though, and decimal representation can also be really long for large values, making it hard to compare values. This CL switches this debug output to hexadecimal float values, which always shows the float value in full precision and is also much shorter than decimal notation in many cases. R=ahaas@chromium.org Bug: chromium:1112099 Change-Id: Ia84824227fcd2f1e763ab89280a202ed44930a71 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346646Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#69323}
-
Marja Hölttä authored
Bug: v8:10239 Change-Id: I5d8e9c85f97835bcabb0c42c7dc0db0fdb3f82fe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2342851Reviewed-by: Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#69322}
-
Lei Zhang authored
32-bit MSVC generates a C4018 warning for signed/unsigned mismatch. Fix this by casting the std::numeric_limits<int32_t>::max() return value. Change-Id: Iaff6b81c797a88654a7d2fa6d910da105d824df8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2346934Reviewed-by: Andreas Haas <ahaas@chromium.org> Commit-Queue: Lei Zhang <thestig@chromium.org> Cr-Commit-Position: refs/heads/master@{#69321}
-