Am 16.12.2013 05:15, schrieb Andrei Alexandrescu:
Hello,
Seems like the low-level allocator is faring quite well. After quite a
bit of thinking on the higher-level allocator, it seems to me I could
attack the entire tracing/GC matter heads-on, possibly ultimately
complementing or even providing an alternative (or more!) for the
existing GC. The fresh modular approach focused on composition could
make it much easier to design and implement high-performance collectors.
Anyhow, I've decided to investigate the issue closer. There is one part
that is very low-level - collecting the roots. It would be awesome if
that could be abstracted into a small, simple API.
There are several major roots - global memory, thread-local storage for
all threads, and stack+registers. Currently all offer ranges of void*.
Assuming we pull the work on precise GC, some of these root sources
would offer ranges of void* + TypeInfo.
I was thinking it would be great to have a range-based API for walking
these entities. With that in place, defining tracing algorithms can be
done modularly and with relative ease. Each range-based API would come
with specifications of how long the ranges are valid and when it's okay
to interrupt and resume iteration etc. Some APIs might possibly switch
to internal iteration, i.e. the user passes a lambda that gets called
for each root.
What do you think?
Andrei
Reading "The Handbook of Garbage Collection" I got the opinion that
doing a generalized tracing API would be a bad idea. In the book they
usually describe tracing as a specialized task depending on what type of
collector is chosen.
Generally I think it is a good idea to think about tracing and identify
all problems the language still has with propper tracing. Because it
seems that this has not been done in the past.
Tracing alone is also not enough. There would also be a need for a
gc-stop point kind of api that inserts points where the GC can stop the
program without corrupting it.
Kind Regards
Benjamin Thaut
--
Kind Regards
Benjamin Thaut
