Hi, On 11-07-2012 01:54, Antti-Ville Tuunainen wrote:
I'm working on the precise gc patches. I now have a bunch of templates and all the other infrastructure, but what's holding me back is that I don't quite understand the .di files.
DI files are exactly what header files are in C(++) (there are some subtle differences, but you can think of them this way). They are merely an interface to the implementation.
We have a few hand-crafted DI files in druntime (object.di and core/thread.di) in order to hide a number of implementation details, while the rest of the DI files for druntime are generated or the implementation files just directly copied.
In order for user-defined datastructures to instantiate the correct templates, the template code needs to live (/be imported into) the object.di file. However, for any kind of efficiency, the templates also need to be able to directly call functions and/or access the state from src/gc/gcx.d. I cannot just import it, because it won't be available during (user code) compilation. What is the correct approach?
Basically gc.* and rt.* are completely internal to the runtime. There is no (unobscure/supported) way to get at these modules.
Can you be more specific as to what information the templates need to get at (or provide)? That is, how will the templates interface with the GC?
Currently, I'm leaning on creating a new public gc.di (or similar), with functions to scan ranges and single pointers, and add implementations of those to the gcx side. Is this the correct way forward?
Not sure. Need more information about the above first. -- Alex Rønne Petersen a...@lycus.org http://lycus.org
