Dynamic Wind for LLVM?

[kyay10]

I'm wondering if any work has been done on combining the Muhcu et al approach to local mutable state (which, to my understanding, is the approach used in the LLVM backend) with the Voigt et al implementation of Dynamic Wind (i.e. onSuspend and onResume clauses).

For one, I think it's okay to ignore finalizers when doing a one-shot resumption, at least for now.

It seems really easy to support onSuspend by modifying invalidate to pause when encountering a finaliser, storing the rest of the segment that it needs to invalidate in some new unwind frame. This works nicely because invalidate works from the top of the stack, all the way to the prompt, thus it's executing onSuspend clauses in LIFO order, which are the desired semantics.

I can't imagine a simple implementation of onResume while keeping the same semantics. revalidate works on the segment from the top of the segment to its bottom, meaning that onResume clauses are discovered in LIFO order (and the revalidation, in general, goes in LIFO order). This is bad because, then, it can't have the necessary resume frame.

This reminds me of Java-Effekt, whose implementation had Segments that went in the opposite order from the stack, thus it would visit frames in FIFO order, which is what we need here.

[kyay10]

One simplification that might help here is to change the Muhcu et al approach slightly:
Instead of having Prompts with a stable address that then point to a heap-allocated data (which contains a stack and a pointer to the next such data), we instead inline those fields directly into Prompt, and our Segments now don't need to be copied every time we resume them (we still copy the individual stacks, obviously, but the linked list of stacks itself doesn't need to be copied), because instead we use it as a store of values that need to be set onto our Prompts. This frees our Segments from being forced to be linked lists, and since they don't need to be copied anymore, we can explore other ways of storing the data. In particular, I've found a lot of success in using a simple array of values (i.e. it stores the stack and next pointers). The array is created when invalidating (using a simple dynamic array by just copying the array if it's full), and is traversed when revalidating (thus updating our Prompts with the correct stack and next pointers, while remembering to copy the stacks of course).
I think this approach might allow for revalidation to occur in FIFO order, thus fulfilling the requirements of onResume.
I will provide a link to my implementation, but it does have some slight differences to the LLVM background (my stacks are actually linked lists of frames since Kotlin forces me to use that, and thus each stack points to its prompt, so a prompt doesn't actually store a stack, and instead it points to the next stack, and has a shortcut pointer to the next prompt. I get the benefit of being able to delay stack copying as a result, though, which helps when resumption ends up suspending shortly thereafter).

Edit: here's a link to the implementation, along with the class hierarchy. It used an array to store the segments value, which allows for very fast invalidation and revalidation. It doesn't have the FIFO revalidation yet, but it has (non-effectful) finalizer frames, which are sufficient to have local mutable state. My code is very reminiscent of Effekt's JS backend, likely because both have some roots in Java Effekt.