Ah fuck my asshole of course it wasn't that easy

Great that my GC can detect any managed pointer off the stack et al. Yeah but what if a GC ptr is behind some random non-gc allocation, inside a future, etc.

fuckkkk

Best idea right now I replacing the global allocator. Then I know all allocations and can conservatively still traverse them (means way more checks... ugh). And if one allloc is a gc object then I know its vtable and can do precise analysis

Really not perfect. But guess what: boehm does the same lol

I should really stop being that dismissive of myself

Check your Snek (DM), that's where the cool stuff is.

Sid, fuck you.

Best idea, stop coding useless shit.

@afaIk Maybe your parents shouldn't have coded your dna

This is an incredibly cool project, but why GC in a compiler? It's like the perfect example of a short-running multi-stage compute-heavy task, one you should back with a set of arenas for each stage if you want to pay attention to memory management at all.

I use Rc but that's because I don't want to care about memory management. If I did, for sure I would use arenas (and investigate whether pointers are actually a good choice while I'm at it, Zig had some interesting findings about that)

@lorentz Arenas would impose some awkward lifetime restrictions if you want to use raw ptrs internally and make it not unsound. Alternatively you could use general indices but then you need to query the arena with a key all the time which is very awkward -- I actually did that before switching to Rc because it was way too annoying

I guess ultimately, I'm doing this because why not :P

And it's gonna be pretty fast too. Using Rcs has some unfortunate codegen. If you have a bunch of short lived Rc clones, each time you drop one it has to check whether it's dead and emit a heavy dealloc branch

it's not easy but with a lot of lube I could shove it in

@antigermanist Its that big huh

@12bitfloat Well. I kinda assumed that the compiler would recognize many cases where the Rc is guaranteed to have other copies and generate a decrement. Actually, why is a heavy branch so important if it's not taken anyway?

@lorentz It's probably fine either way :P

But the issue with "heavy" branches that contain function calls, etc -- even if they are very rarely taken -- is that it pessimizes everything else around it, especially register allocation. And in case of the Rc decrement, I think that can panic aswell, which requires the codegen to do some stuff for unwinding too

@lorentz Just look at the codegen difference: https://godbolt.org/z/vsTeGcz8M

Pretty crazy