[RFC]Proposal for better garbage collection
H. S. Teoh
hsteoh at quickfur.ath.cx
Wed Feb 22 13:45:37 PST 2012
On Thu, Feb 23, 2012 at 12:03:59AM +0400, Dmitry Olshansky wrote:
> >7) Compiler Options
> >Each of the above mentioned groups of features should be exposed as
> >compiler options so that you can turn them on/off depending on which
> >type of GC you use. Default on/off states for these features are set
> >within a config file depending on which type of GC currently ships
> >per default with druntime.
> Combinatorial explosion of sets of options that doesn't necessary
> allow a particular GC?
Yeah, this is not a good way to go. Better would be for each GC come
with a GC description file, that describes what hooks/info it needs from
the compiler. Then the compiler can read this description file (passed
as a *single* compile flag) and do the right thing for that particular
GC. It can even automatically link in that particular GC without needing
you to specify anything further.
The GC description file can contain info like:
- Where/when to insert calls to GC functions (e.g., start collect cycle,
start mark cycle)
- Which function to use for allocating memory
- Any additional info required:
- e.g., map of each function's pointer local variables so that the GC
knows where the roots are;
- Whether or not hooks are needed for function entry/exit, and which
GC function to map them to;
- Any additional GC-specific info to insert into functions / structs /
- Whether or not pointer reads/writes need to include GC-specific code
(the description can include code to insert, if needed).
- Path to GC source(s) to be compiled into the program.
If Java had true garbage collection, most programs would delete
themselves upon execution. -- Robert Sewell
More information about the Digitalmars-d