Permalink
Reply
On Sunday, 3 April 2022 at 02:45:45 UTC, Evan Ovadia wrote:
>I'll add some details on improvements made since that original article, which could help explain why this seemingly crazy scheme might work well:
Thanks! (I still need to read these).
>- If we want to, we can lock an object to prevent it from being freed at runtime, which is a good call in some cases and can let us skip a lot of generation checks:
That's an interesting idea. So for a mutable object shared across threads in D, an atomic int could be incremented before dereferencing fields. Any intervening call to free the object would be deferred by the allocator until after the dereferencing. And this should have better cache locality than atomic reference counting.
>If D wants to use any of these ideas, just give me a holler! Always happy to discuss.
I'd prefer D supported generational references instead of @live which seems to be like rust's unique mutability. Failing that perhaps generational references can be supported in a D library, but they'd only work with compatible objects.