-
Notifications
You must be signed in to change notification settings - Fork 165
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
Modified finaliser to collect subregions #90
Conversation
bf5967a
to
eef4a62
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is definitely an improvement!
Just to confirm, is this a fix for #83? Should there be a new test case added?
This doesn’t support extracting another object’s field in a finaliser, as that other object’s own finaliser could have added it to the stack. What’s your “long term” plan about this? I really think this should be happening in the destructor, not the finaliser. Unfortunately we can’t do this without pointer tagging. |
My short term plan is for
Personally, I prefer the first as I think it is easier to explain, and has fewer special cases. But the second might enable more refactorings for subobjects. |
Yes, forgot about that. I'll add a test case. Good catch. |
o->finalise(); | ||
// We don't need the actual subregions here, as they have been frozen. | ||
ObjectStack dummy(ThreadAlloc::get_noncachable()); | ||
o->finalise(nullptr, dummy); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't really an issue, but the behaviour of finalise on immutables in the VM and in C++ code will be different. In the VM, it will add “subregions” as the tag is still ‘ISO’. However in the C++ tests, where we use the object header bits, the bits accurately represent the frozen state and they won’t be added.
I think it's worth noting this somewhere, either here or in object.h.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure quite where that comment should go, as I would sooner not discuss the interpreter in the runtime. The compiler will not track things dynamically, so will depend on the runtime. I could change the interpreter to behave the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't review this code as I'm not entirely familiar with the concepts yet, but it does seem clearer to me to mark and call finalisation when we know they'll have to be done instead of tracking ISO
s around.
Added a nit comment, but that's it from me.
9a11279
to
a2b7251
Compare
The finaliser must return the subregions that this object owns that will require collection. This removes the need for the hacky `trace_possibly_iso` that was used during deallocation. This simplifies the ordering of deallocation. The most general semantics the runtime supports is > self is mutable, but any mutable object it > refers to is read-only This implementation still allows the extract to function during finalisation. We may wish the language to be more restrictive, i.e. everything read-only during finalisation.
a2b7251
to
07390a5
Compare
07390a5
to
f13b01e
Compare
The finaliser must return the subregions that this object owns that will
require collection. This removes the need for the hacky
trace_possibly_iso
that was used during deallocation. This simplifiesthe ordering of deallocation. The most general semantics the runtime
supports is
This implementation still allows the extract to function during
finalisation. We may wish the language to be more restrictive, i.e.
everything read-only during finalisation.