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

Is it safe to panic when zerogc is used? #23

Open
playXE opened this issue Mar 10, 2021 · 2 comments
Open

Is it safe to panic when zerogc is used? #23

playXE opened this issue Mar 10, 2021 · 2 comments

Comments

@playXE
Copy link

playXE commented Mar 10, 2021

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.

@Techcable
Copy link
Member

Techcable commented Mar 16, 2021

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 trigger_safepoint method should only run garbage collector code and (trusted) Trace implementations. The safepoint_recurse! macro is built to handle both panics and leaks in user code.

On the other hand, panicking inside a Trace implementation is probably undefined behavior (but I am not sure). It's tough for me to think through panicking in the middle of garbage collection 😕 The first problem is that it doesn't make much sense for a trace function to safely 'fail'. Either you correctly told the garbage collector about all your pointers, or you have not. If you have not (and missed some), you're already going to trigger undefined behavior because the garbage collector will free those pointers you forgot to trace.

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:
If you run into any issues with panicking in normal code, then that's a very serious bug!! 💣
If you run into any issues panicking inside an unsafe trait, then it's a minor bug that I'm not in a big hurry to fix.

Thanks for your interest in zerogc 😄

@playXE
Copy link
Author

playXE commented Mar 17, 2021

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 :)

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

No branches or pull requests

2 participants