-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve GC performance by using typed interface to bdwgc #1239
Draft
plajjan
wants to merge
9
commits into
main
Choose a base branch
from
gc-descriptors
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains 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
7f5af06
to
444f048
Compare
785fca1
to
1906d5e
Compare
We now generate a GC descriptor for structs. It describes the memory structure, where there are pointers, to the GC. The descriptor itself is stored in the _class struct in the first field. The old $GCINFO was meant for this type of GC information but we never got around to using it before, instead it held a string of the name of the object class - useful for debugging. We still think that's useful so we keep the name but it is now stored in $name - slightly more intuitive. The GC descriptor is built from a bitmap. As it can vary in size, it is kept outside of the _class struct as a new global of the name ClassD_gcbm.
This adds GC descriptors for most of the C code we have checked in, like builtins and RTS. Mallocs have been turned into GC_MALLOC_EXPLICITLY_TYPED with a corresponding GC descriptor stored in the method table of the associated class. The GC descriptor is in turn based on a GC bitmap, which is of varying length and thus not suitable for placing directly in the method table. There are instead separate global variables, one per class. We initialize these structures a bit differently, so where there are static initializations the bitmap is currently initialized to 0, which is usually wrong as it indicates that the GC should not scan the object. For classes initialized with a method table, as the current code generated by actonc, we currently set it to 0xFF, as to indicate all bits should be scanned. The goal right now is just to add in the GC descriptors and start using them for allocations without breaking anything. We will start fiddling with the bits later on to speed things up.
We err on the safe side by initializing the GC bitmaps to all 1s which means they will be scanned in their entirety.
A little cleaner I think! :)
Set correct GC bitmaps for all builtin types!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
No description provided.