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

Modified finaliser to collect subregions #90

Merged
merged 3 commits into from
Jun 8, 2020
Merged

Conversation

mjp41
Copy link
Member

@mjp41 mjp41 commented Mar 6, 2020

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.

@mjp41 mjp41 requested a review from plietar March 6, 2020 14:55
@mjp41 mjp41 force-pushed the refactor-finalisation branch 3 times, most recently from bf5967a to eef4a62 Compare March 6, 2020 16:49
@mjp41 mjp41 requested a review from mhyee March 6, 2020 16:51
Copy link

@mhyee mhyee left a 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?

src/interpreter/object.cc Outdated Show resolved Hide resolved
src/interpreter/object.cc Outdated Show resolved Hide resolved
src/rt/region/region_arena.h Outdated Show resolved Hide resolved
@plietar
Copy link
Contributor

plietar commented Mar 7, 2020

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.

@mjp41
Copy link
Member Author

mjp41 commented Mar 9, 2020

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 finalisers to be have read-only self parameters. Longer term there seem to be two possibilities:

  • Treat self as mutable, but not reachable objects.
  • Treat iso fields as mutable, but not other fields of self.

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.

@mjp41
Copy link
Member Author

mjp41 commented Mar 9, 2020

Just to confirm, is this a fix for #83? Should there be a new test case added?

Yes, forgot about that. I'll add a test case. Good catch.

src/rt/object/object.h Show resolved Hide resolved
src/rt/object/object.h Show resolved Hide resolved
o->finalise();
// We don't need the actual subregions here, as they have been frozen.
ObjectStack dummy(ThreadAlloc::get_noncachable());
o->finalise(nullptr, dummy);
Copy link
Contributor

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.

Copy link
Member Author

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?

src/interpreter/object.cc Outdated Show resolved Hide resolved
src/interpreter/object.cc Outdated Show resolved Hide resolved
Copy link
Contributor

@rengolin rengolin left a 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 ISOs around.

Added a nit comment, but that's it from me.

src/interpreter/value.cc Show resolved Hide resolved
@mjp41 mjp41 force-pushed the refactor-finalisation branch 3 times, most recently from 9a11279 to a2b7251 Compare June 8, 2020 13:40
mjp41 added 2 commits June 8, 2020 14:57
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.
@mjp41 mjp41 merged commit fe80d41 into master Jun 8, 2020
@mjp41 mjp41 deleted the refactor-finalisation branch June 8, 2020 19:13
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.

None yet

4 participants