On 4/16/2012 2:05 AM, deadalnix wrote:
Having this template into object.d seems problematic to me. It is now quite hard
to provide any custom GC implementation without messing with Druntime.
Providing a user created GC should be as easy as possible.
It's never going to be easy for anyone to just write their own GC, especially
one that works better than one a lot of people have spent a lot of time on.
I think this is again solving an implementation issue by a language design
decision. Ultimately the useless code bloat must be handled by the toolchain
anyway.
We gotta work with what we have.
6. I suggest the GCInfo pointer be stored at the end of the allocated
block, as then it won't affect the alignment of the allocated data.
This very swap unfriendly. Many pages will have to be unswapped/swapped back in
the marking process, even if it is 100% useless for data that doesn't contains
pointers.
I think there's a misunderstanding. The GC allocates by powers of 2. So a 22
byte struct will be allocated in a 32 byte block, and the GCInfo pointer can go
at the end of that. That will not cause swapping.
As for data that has no pointers, something has to indicate that. Of course,
another strategy is to allocate such data in separate pools. In fact, that might
be an excellent idea, as such pools would never have to be read (i.e. swapped
in, loaded into cache) during the mark/sweep process.
