Le 16/04/2012 11:25, Walter Bright a écrit :
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 don't think this is easy. But Different GC have different impact on
the program. For instance, oracle's JVM provide you 4 different GC, that
you can choose with different configuration parameters.
Some are made to achieve maximum throughput, others to achieve low
pause. None is better that the other, it depends on the application. For
a user interface, you'll chose the low pause GC, but for a backend
processing application, you may prefer the maximum throughput.
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.
That is exactly what I meant. Metadata about the block shouldn't be
stored anywhere near the block, because it will behave horribly wrong
when swap come into play. Metadata must be read and written when GC does
its job, but the block itself doesn't require it.
