runtime (gc_blocks.go): use a linked stack to scan marked objects #5102
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Author
|
This includes the commit from #5101, so that should be merged first. |
Member
Author
|
This improves performance significantly: |
Member
The blocks GC originally used a fixed-size stack to hold objects to scan. When this stack overflowed, the GC would fully rescan all marked objects. This could cause the GC to degrade to O(n^2) when scanning large linked data structures. Instead of using a fixed-size stack, we now add a pointer field to the start of each object. This pointer field is used to implement an unbounded linked stack. This also consolidates the heap object scanning into one place, which simplifies the process. This comes at the cost of introducing a pointer field to the start of the object, plus the cost of aligning the result. This translates to: - 16 bytes of overhead on x86/arm64 with the conservative collector - 0 bytes of overhead on x86/arm64 with the precise collector (the layout field cost gets aligned up to 16 bytes anyway) - 8 bytes of overhead on other 64-bit systems - 4 bytes of overhead on 32-bit systems - 2 bytes of overhead on AVR
Loop over valid pointer locations in heap objects instead of checking if each location is valid. The conservative scanning code is now shared between markRoots and the heap scan. This also removes the ending alignment requirement from markRoots, since the new scan* functions do not require an aligned length. This requirement was occasionally violated by the linux global marking code. This saves some code space and has negligible impact on performance.
niaow
force-pushed
the
blocks-linked-list
branch
from
cfbf6c9 to
11d283d
Compare
Member
Author
|
I also decided to add the scanning logic rework commit to this PR because it is closely related. |
deadprogram
approved these changes
Dec 4, 2025
Member
deadprogram
left a comment
deadprogram
left a comment
There was a problem hiding this comment.
I think the small header justifies the speed increase. From my initial benchmarks it does appear to have an impact on the larger nested/linked data struct.
Member
|
Here my my benchmarks from tinybench: BeforeAfter |
Member
|
Anyone else have any feedback before we merge? |
dgryski
approved these changes
Dec 4, 2025
Member
dgryski
left a comment
dgryski
left a comment
There was a problem hiding this comment.
The gc_blocks and gc_conservative work LGTM, but I wouldn't mind a second set of eyes on the gc_precise changes.
Member
I gave it a few more goings over and still LGTM. Now merging, thanks @niaow for all this awesome work! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The blocks GC originally used a fixed-size stack to hold objects to scan. When this stack overflowed, the GC would fully rescan all marked objects. This could cause the GC to degrade to O(n^2) when scanning large linked data structures.
Instead of using a fixed-size stack, we now add a pointer field to the start of each object. This pointer field is used to implement an unbounded linked stack. This also consolidates the heap object scanning into one place, which simplifies the process.
This comes at the cost of introducing a pointer field to the start of the object, plus the cost of aligning the result. This translates to: