On Sunday, 15 November 2020 at 22:29:27 UTC, Rainer Schuetze wrote:
> It would disallow some patterns, for example intrinsic lists, with the node of a list being part of a larger struct, and the offset to the start of the struct is known.

Yes, but after som thought, is it unreasonable to require owning GC pointers to be free of pointer arithmetic?

Developers could mark such listpointers as nonowning, then they would not have to be scanned.

Btw, gc_emplace is clearly better than the current approach, but I think about using just the vtable pointer address for class id, or to embed a class id in each object.

If we have 100% accurate tracing then it is possible to let the compiler generate code for the whole collection cycle (and the allocator). One could even profile pointer and allocation statistics and use that for code gen optimizations.