Sweeping with single-threaded GC

[Erik Corry]

We run with --single-threaded-gc.  It looks like no sweeping of old space takes place until the next old-space GC starts up.  Does this sound likely?  I'm putting a breakpoint in Sweeper::RawSweep, and it's not hit between old-space-GCs, even though the GC state is SWEEPING.  Is there
a different place that does the sweeping work?

[Omer Katz (chromium.org)]

Sweeping happens either concurrently (disabled by --single-threaded-gc) or on allocation if we will otherwise run out of memory.

It's possible that you don't hit the cases that would require sweeping on allocation.

On Wed, Nov 13, 2024 at 4:49 PM Erik Corry <erik...@chromium.org> wrote:

We run with --single-threaded-gc.  It looks like no sweeping of old space takes place until the next old-space GC starts up.  Does this sound likely?  I'm putting a breakpoint in Sweeper::RawSweep, and it's not hit between old-space-GCs, even though the GC state is SWEEPING.  Is there
a different place that does the sweeping work?

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHZxHpiAZ0EQNJFmubnwvVxtVAu1vJTFg-1AXNEXeX8ojMqazg%40mail.gmail.com.

[Erik Corry]

I see.  I was just confused because the GC state stays in SWEEPING until the next big GC, even when all pages have been swept.

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAJFGqfO8RRmOh6sbeu4AckMf%2B0FqNoh%3D-7W%3DAn1SjNGgo6o0wQ%40mail.gmail.com.

[Omer Katz (chromium.org)]

Hi Erik,

Yeah, I see how that can be confusing.

In my previous answer I assumed you meant there are pages that are only swept when we start the next GC, which is uncommon but possible.

What you're describing now, where all pages are swept but the GC remains in a sweeping state, is very likely and intentional.

Sweeping the pages can happen either concurrently or during allocations.

Switching state happens after all pages are swept but can be delayed.

Finalizing sweeping, and the state change that goes with it, requires some accounting work which, for performance reasons, we don't want to do during an allocation (it also has to happen on the main thread so can be concurrent).

Therefore the state remains as is until we can "safely" (i.e. without incurring an unnecessary performance cost) finalize sweeping, which is usually when we start the next GC (minor or major).

I hope that clarifies things.

Omer

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHZxHpjKD%3DUAWs5E3yvP9%3Douc%2BA2-6xcqBc6%3DS-HG9z0s4n6Pw%40mail.gmail.com.

[Erik Corry]

Thanks for the clarification, but the state doesn't flip on the next minor GC, it has to wait for the next major GC.

On a minor GC the state is saved in previous_ and after the minor GC it is restored, so nothing that happens in the minor GC can change the state from SWEEPING to NOT_RUNNING.

It probably doesn't matter.  Presumably the distinction between SWEEPING and NOT_RUNNING doesn't affect performance?

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAJFGqfPGM33z%3DF9QX%3Du1pUXf_39nfJPSvMA03SEeUd%3D0VD8nEA%40mail.gmail.com.

[Omer Katz (chromium.org)]

The state can change on minor GC (before it the GC is even started) if all pages are already swept.

Since you disable concurrent sweeping, most likely not all pages are swept, thus the state does not change.

To view this discussion visit https://groups.google.com/d/msgid/v8-dev/CAHZxHpiQJMG68dp66ydki7uQVVc2ga_%3Djkr54ercKpYdYNE9OA%40mail.gmail.com.