Techcable
commented
3 years ago 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 :confused: 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!! :bomb:
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 :smile:
playXE
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.