-
Notifications
You must be signed in to change notification settings - Fork 2
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
Is it safe to panic when zerogc is used? #23
Comments
It depends on where the panics are. If there is a panic in the user's main code, there should be no problem. That's something I designed for. The On the other hand, panicking inside a From a more practical standpoint, garbage collection is extremely complex and uses a lot of unsafe code internally. Supporting what is essentially an 'exit' and cleanup from any time during garbage collection is really hard to do.` I think panicking from inside a Trace function is something I'll someday support safely. I'll probably decide to exit the garbage collection early and refuse to free any memory at all (until the GC tries again later). The documentation has it listed as allowed behavior even though I haven't really tested or implemented it. Summary: Thanks for your interest in zerogc 😄 |
Thanks for answer! My question was about panicking in safepoint_recurse! macro. I'm still not moving from mostly-precise collector in starlight since support for precise collection is quite hard to do while conservative stack scanning is easy. Will move to zerogc when object-safe allocation will be possible and finalizers will be implemented :) |
I want to use zerogc to implement main GC algorithm in starlight but there is question: is it safe to panic and then catch panic when zerogc shadow stack is used? As I understand when panic happens zerogc does not at all try to remove shadow stack entries which leads to UB.
The text was updated successfully, but these errors were encountered: