> That's where much of the overhead comes from, needing to repeatedly trace the full set of program references
No modern GC goes over naively the full application, generational GCs basically group together objects and cache their inter-generational references.
Also, I don’t really get what you mean. What reference could be - regardless of language - that is not related to the life cycle of the targeted data? That reference can only be invalid in such case, so, the inverse of the life cycle which is absolutely related. Sure, a pointer can be encoded many smart ways, but in the end they either point to a semantically correct data location or not.
Generational GC's simply have multiple "generations" assigned by age, that get traced at different frequencies - the "younger" generation more frequently than "older" ones. Any caching involved is strictly temporary and does not obviate the need to "go over" the full set at some point. The alternative is a lot of memory overhead.
> What reference could be - regardless of language - that is not related to the life cycle of the targeted data?
If a program reference can be statically proven to never outlive the object it targets, it's per se irrelevant to that object's lifecycle. That's what the borrowck pass in Rust is all about.
No modern GC goes over naively the full application, generational GCs basically group together objects and cache their inter-generational references.
Also, I don’t really get what you mean. What reference could be - regardless of language - that is not related to the life cycle of the targeted data? That reference can only be invalid in such case, so, the inverse of the life cycle which is absolutely related. Sure, a pointer can be encoded many smart ways, but in the end they either point to a semantically correct data location or not.