Skip to content
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

Add tag for tracking if object is RAII'd or GC'd #25

Merged
merged 1 commit into from
Sep 16, 2024

Conversation

jacob-hughes
Copy link

To support finalizer elison in Alloy, we need a new way to differentiate between RAII (non-GC'd) and GC'd objects such that this status can be changed dynamically. Currently in BDWGC, if we use GC_malloc and GC_malloc_uncollectable for this distinction, there is no way to change this after an object has been allocated. Using a spare bit in the mark header is a convenient way for us to tell the sweep phase whether or not an object should be considered garbage or whether it is uncollectable while allowing it to be changed in the future.

mark.c Outdated
GC_ASSERT(n_marks != 0);
clear_uncollectable_bit_from_hdr(hhdr, bit_no);
n_marks--;
hhdr -> hb_n_marks = n_marks;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for the "read into n_marks, then decrement it, then write it" dance? If I did something like:

GC_ASSERT(hhdr->hb_n_marks != 0);
clear_uncollectable_...
hhdr->hb_n_marks --;

would this still be correct?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've looked into this and realised that I'd confused things here. We don't want to adjust the marks at all when hopping between collectable / uncollectable objects. I've pushed a fix here: c65972b

@ltratt
Copy link
Member

ltratt commented Sep 13, 2024

Please squash.

To support finalizer elison in Alloy, we need a new way to differentiate
between RAII (non-GC'd) and GC'd objects such that this status can be
changed dynamically. Currently in BDWGC, if we use GC_malloc and
GC_malloc_uncollectable for this distinction, there is no way to change
this after an object has been allocated. Using a spare bit in the mark
header is a convenient way for us to tell the sweep phase whether or not
an object should be considered garbage or whether it is uncollectable
while allowing it to be changed in the future.
@jacob-hughes
Copy link
Author

Squashed

@ltratt ltratt added this pull request to the merge queue Sep 16, 2024
Merged via the queue into softdevteam:master with commit a1b1276 Sep 16, 2024
22 of 367 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants