Tracing API?

[Jacob Carlborg]

On 2013-12-16 05:15, Andrei Alexandrescu wrote:
> 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?

Is this supposed to be used by druntime? If that's the case then there 
is potentially quite a lot of functionality from std.range and 
std.algorithm that is needed in druntime. How should that be handled?

-- 
/Jacob Carlborg