- 09 Jun, 2021 2 commits
-
-
Santiago Aboy Solanes authored
Similar to https://crrev.com/c/v8/v8/+/2270548, we can add an early return since we will not be creating thin strings while single_generation is on. Bug: v8:7790, v8:10614 Change-Id: Ib6ccc00bc79058daa163920a944ad328515f667e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2948888 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#75042}
-
Santiago Aboy Solanes authored
It was added years ago and in 2017 it was enabled by default[1], which means enough time has passed and we can remove the flag. [1]: https://chromium-review.googlesource.com/c/v8/v8/+/528076/ Change-Id: I059417d4683910e86ebfddd93f504006094fa342 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2947406Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#75039}
-
- 07 Jun, 2021 1 commit
-
-
Santiago Aboy Solanes authored
We have recursive calls such ThinStrings where we go String::Get into ThinString::Get into String::Get again for the internalized string. If we need to, we would acquire the StringAccessGuard in the first String::Get and it wouldn't be needed to be re-acquired for the second String::Get. Trying to re-acquire it would in fact be an error since we are already holding the lock. The code, however, didn't know if we acquired it or not. It was working correctly due to the way the methods were defined and called. By passing down the access guard through the Get() calls we make this interaction explicit. Also add some thin string tests to test the interaction. Bug: v8:7790 Change-Id: I1181edec1e802cb754c4d1d1ac268577257b92f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2936598 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74984}
-
- 17 May, 2021 1 commit
-
-
Santiago Aboy Solanes authored
This ends up cleaning up the last of the macros in object-macros which were using `synchronized_`. There are still a few methods which use `synchronized_` but those were defined ad-hoc (i.e. w/o macros). Bug: v8:7790 Change-Id: Ib2d35030fd032293e746c09e10156e526af8d032 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2897085Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#74589}
-
- 01 Feb, 2021 1 commit
-
-
Ulan Degenbaev authored
The flags are enabled by default and have stable coverage. This also removes the corresponding bots. Bug: v8:10315 Change-Id: Icce01383050dff758b6554db8e0c3589d6e5459c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2658324 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#72457}
-
- 15 Jan, 2021 1 commit
-
-
Santiago Aboy Solanes authored
This reverts commit 3a6f75ac. Reason for revert: performance regressions https://bugs.chromium.org/p/chromium/issues/detail?id=1163063 Original change's description: > [objects] Remove MakeExternal case for uncached internal strings > > Concurrently accessing internal external uncached strings is not > thread-safe. We are removing a case where we can make such a string > through MakeExternal. > > Bug: v8:7790 > Change-Id: I958062c15cf40ccc330600bb572de98620866e54 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 > Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71573} TBR=leszeks@chromium.org,solanes@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:7790 Change-Id: I5dcc734869c3c921eacd89426309141127a85f47 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2633547Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72123}
-
- 02 Dec, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Concurrently accessing internal external uncached strings is not thread-safe. We are removing a case where we can make such a string through MakeExternal. Bug: v8:7790 Change-Id: I958062c15cf40ccc330600bb572de98620866e54 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565511 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#71573}
-
- 25 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Pass the Isolate/LocalIsolate through to StringTable matchers and WriteToFlat, so avoid having to get the Isolate via the String, and to avoid locking on the main thread entirely. This allows us to remove the String overload of the SharedStringAccessGuardIfNeeded constructor entirely, to avoid this anti-pattern in the future. Bug: chromium:1146972 Change-Id: I53bba126b105e1c9629d6e64d8bb574e62e3ad45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2557988 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71398}
-
- 23 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
If we have a regular isolate (or none at all), we can skip acquiring the lock check and DCHECK that we are calling from the main thread. If we have a LocalIsolate, we acquire the string lock if needed. Bug: v8:7790 Change-Id: Ie3562e8172a3e3eca8d194e8652cb881f765cdb8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2551102 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#71340}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 19 Nov, 2020 1 commit
-
-
Dominik Inführ authored
This is a reland of e95e1b62 After landing https://crrev.com/c/2546682, this CL can be relanded without changes. Original change's description: > [heap] Introduce LocalIsolate for main thread > > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is > kept alive during the whole lifetime of the Isolate. The main thread > LocalIsolate starts in the Running state in contrast to the background > thread LocalIsolates (those start in Parked). > > Code paths in Turbofan that used to create a LocalIsolate on the main > thread can now simply use the main thread LocalIsolate. > > LocalIsolate for the main thread will help in reducing differences > between the main and background threads. The goal is that the main > thread behaves more like a background thread. > > The main thread LocalIsolate should also make it simpler to share code > between main thread and background threads by using LocalIsolate for > both. > > Bug: v8:10315 > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593 > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71226} Bug: v8:10315 Change-Id: I418b1217aeac4f3c44a0aa514dea9864f8a58656 TBR: szuend@chromium.org, yangguo@chromium.org, ulan@chromium.org, leszeks@chromium.org, neis@chromium.org Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543399Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71274}
-
- 17 Nov, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit e95e1b62. Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm%20-%20sim%20-%20debug/23064 Original change's description: > [heap] Introduce LocalIsolate for main thread > > Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is > kept alive during the whole lifetime of the Isolate. The main thread > LocalIsolate starts in the Running state in contrast to the background > thread LocalIsolates (those start in Parked). > > Code paths in Turbofan that used to create a LocalIsolate on the main > thread can now simply use the main thread LocalIsolate. > > LocalIsolate for the main thread will help in reducing differences > between the main and background threads. The goal is that the main > thread behaves more like a background thread. > > The main thread LocalIsolate should also make it simpler to share code > between main thread and background threads by using LocalIsolate for > both. > > Bug: v8:10315 > Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593 > Reviewed-by: Simon Zünd <szuend@chromium.org> > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/master@{#71226} TBR=ulan@chromium.org,yangguo@chromium.org,neis@chromium.org,leszeks@chromium.org,szuend@chromium.org,dinfuehr@chromium.org Change-Id: Ia70b4bfe3b8fa26bf8d6a7dc612a310b0ed54073 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:10315 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2543937Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#71228}
-
Dominik Inführ authored
Add a LocalIsolate for the main thread to Isolate. This LocalIsolate is kept alive during the whole lifetime of the Isolate. The main thread LocalIsolate starts in the Running state in contrast to the background thread LocalIsolates (those start in Parked). Code paths in Turbofan that used to create a LocalIsolate on the main thread can now simply use the main thread LocalIsolate. LocalIsolate for the main thread will help in reducing differences between the main and background threads. The goal is that the main thread behaves more like a background thread. The main thread LocalIsolate should also make it simpler to share code between main thread and background threads by using LocalIsolate for both. Bug: v8:10315 Change-Id: I7fd61d305a6fd7079e2319d75c291c1021e70018 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2509593Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#71226}
-
- 12 Nov, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I7a7ed66f66e723192a45a05e68e20c11b8262598 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2495460 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71142}
-