unique ownership + unlimited safe generational references

IGotD- nise at nise.com
Tue Mar 29 17:40:27 UTC 2022


On Tuesday, 29 March 2022 at 17:13:57 UTC, Nick Treleaven wrote:
> Hi,
> This article is from 2021:
> https://verdagon.dev/blog/generational-references
>
> I've not seen Generational References mentioned on this forum 
> but Reference Counting comes up a lot. I thought GR would 
> interest people here. The article shows a benchmark based on 
> naive RC vs naive GR, but the explanations why it was faster 
> are interesting and promising. (I found this yesterday, I don't 
> know yet if there is more info elsewhere).
>
> The author explains why they believe aliasing of references was 
> more common than dereferencing:
> https://www.reddit.com/r/ProgrammingLanguages/comments/kpq805/vales_generational_references/gi0zmnn/
>
> RC & GR aren't functionally equivalent, the memory is freed 
> when the single owner goes out of scope. Any remaining 
> references would then either halt or throw when dereferenced. 
> So that's a pitfall you don't have with RC, but at least it's 
> deterministic. And no lifetime annotation or restriction to 
> only unique mutability a la Rust. So the programmer has more 
> flexibility.
>
> It also reminded me of a Microsoft idea to make calling `free` 
> memory-safe, but I never found any detail on how that worked or 
> what the overhead was.

In general I think that unique ownership of pointers is a plague 
in computer science and it needs to die. The reason is that it is 
fundamentally data structure unfriendly.

When it comes to the memory management described here 
(Generational References), it is like a runtime version of the 
borrow checker in Rust (not completely, but close). It solves use 
after free but what does it solve beyond that? Also, does need to 
do a check for every deference?



More information about the Digitalmars-d mailing list