Automated cleanup tied to scope, like destructors (__deinit?) or defer

[juliusikkala]

Lately, I've been using Slang on CPU quite a bit, both for fun (working on an SDL2 + Vulkan minigame with Slang on both CPU & GPU) and academic reasons (fitting various curves, using auto-diff). Having amassed quite a bit of CPU-side code, probably the least "fun" thing about Slang in that context has been the cleanup of resources.

This is pretty much a non-issue on the GPU side, since rarely if ever do shaders care about resource (de)allocation, but on the CPU side, it's unavoidable in non-trivial programs. The best I can come up with current Slang is similar to C but without even the goto fail; pattern typical in C codebases. This can lead to lots of error-prone repetition, e.g. something like the following:

// List<T> here is a dynamic array type similar to std::vector<T> and involves a heap allocation
List<VkLayerProperties> availableLayers;
// ... fill in availableLayers
if(!createInstance(...)) {
    availableLayers.free();
    return false;
}

List<VkPhysicalDevice> physicalDevices;
// ... fill in physicalDevices
if(!selectDevice(...)) {
    availableLayers.free();
    physicalDevices.free();
    return false;
}

List<VkExtensionProperties> deviceExtensions;
// ... fill in deviceExtensions
if(!createDevice(...)) {
    availableLayers.free();
    physicalDevices.free();
    deviceExtensions.free();
    return false;
}
availableLayers.free();
physicalDevices.free();
deviceExtensions.free();
return true;

Because there are no destructors, resources have to be freed manually at all the places where the function may exit. It's also a bit asymmetric since constructors exist and can execute non-trivial code (allocate resources). Here's a couple of ideas I could come up with to help this situation:

1. OOP-style destructors: __deinit would match nicely with __init. In practice, this would also require either the existence of user-overridable copy construction & assignment operator or banning copying for types which implement __deinit. Without those, a naively copied structure would quickly lead to double freeing as both copies free the same resource in __deinit. I'm not super familiar with auto-diff for custom types, but if I were to make this List<T> differentiable, a __deinit would also allow the auto-diff'd code to release the memory of the differentiated type, right?

2. defer: Although it's a bit more verbose and somewhat more error-prone (and I personally dislike it), something like the defer keyword from Go, Zig, Odin, etc. could also be a great quality-of-life improvement for this purpose, without necessarily needing the copy/assignment stuff. It's also a very non-invasive feature, which is nice too for those who don't want to use it or if another destruction method is implemented later on. defer can also allow passing parameters to the "destructor", which in my case would actually be useful for wrapped Vulkan resources which need a VkDevice handle for destruction. I can also imagine some use cases for defer in compute shaders, e.g. if there's a "mutex" implemented with atomics, one could defer the unlock to the end of the scope. Not sure if defer would help in the auto-diff case, though.

3. GC or reference counting: This is probably not going to fly considering the target audience, but just listing it here for completeness 😉

[csyonghe]

My thinking is that we will need all three of them in the language.

Slang class is already automatically reference counted, but we still need to add destructors, or something like IDisposable so that they can be called upon the destruction of a class object.

defer is within our considerations of features to add too, and it aligns well with the try keyword that is already partially implemented in the compiler.

[juliusikkala]

Interesting! I didn't find this documentation earlier but found it now, sorry for missing that.

I think destructors for structs could also be implemented as a "syntactic sugar" on top of defer; each variable declaration would generate a deferred call to the destructor like below:

MyDestructible inst;
// auto-inserted by compiler
defer inst.__deinit();

Unless someone is actively working on it currently or sometime soon, I'm interested in trying to implement defer myself (at a relaxed pace). I suppose it could be an IR instruction that gets lowered sometime after generics lowering, so that it could be used with destructors later (which may or may not exist depending on the generic type).

Handling of defer statements is actually the hardest part of this proposal

sounds a bit scary, but it might be fun to try anyway. At least I'll learn something in the process 😄

[csyonghe]

We will appreciate your patch to implement defer! It will be an important feature for Slang to be a good heterogeneous/CPU language.

I agree with you that lowering of defer should be done in the IR level, possibly immediately after IR lowering, and before the first call to the inline pass so things like inlining and autodiff does not need to know about defer.

We would introduce an IRDefer opcode that appears as an ordinary instruction, and code inside defer block will lowered as children insts of IRDefer.

During lowering pass, for every basic block, we collect all IRDefer instructions dominating the basic block, and then we check if the basic block is ends with a unconditional jump or return inst where the destination is not dominated by any dominating IRDefers. Then for each non dominating IRDefer in reverse order, we copy the children instructions of that IR defer right before the jump.

After processing all blocks, the children insts in all IRDefers must have been duplicated at exits sides of the region the defer belongs to, and we can safely remove all the IRDefer instructions. Now we will have ordinary IR without any IRDefers. This solution leads to duplication of code, but should be relatively simple to implement.

If we decide to allow nested defer statements, then we need to repeat the above process until there is no IRDefers left.