[gclist] gc interface

[Francois-Rene Rideau]

> It seems to me from reading various gc papers and this mailing list,
> that the performance of various gc techniques is highly dependent on the
> properties of the application.  So, one should give some control to the
> application programmer, right?  Allow the programmer to pick and choose
> different algorithms, tune the various parameters, etc.
   I already posted on the subject recently, with no answer.
Perhaps I don't look serious enough,
but then, no one even bothered to tell me so :( :( :(
I might be on everyone's killfiles;
not that there wouldn't be reasons,
but I think that would be exaggeration.

> Is there any research, or has anybody thought about, how to do this?
> Ideally, one would have a well-defined interface between gc, mutator,
> and compiler.  And one could plug in different gc algorithms, different
> allocators, etc.  And everything would be plug compatible.  Sounds
> impossible, since gc is inherently a global issue.
   It *is* possible, but not given current state of language technology,
and you'd have to implement the whole compile to make it happen.
And because GC is only a few % in performance,
as compared as the rest of the compiler that would have to be rewritten,
and there is no tight collaboration between GC people and compiler people,
no one bothers to undertake such a project.
   Which is sad, because it would be quite a good thing.
Surely it will be done when language technology,
with partial evaluators, meta-compilers, et al,
are available in a formally safe modular way.
Which is why the fight might be to develop such a facilities first.
But no one seems to actively seek such facilities in a consistent way.

> But maybe some subset of that functionality is feasible.
   Yes, and that's precisely what I just asked for, with no answer.

> Even within a single program.
> Perhaps part of my program could [benefit from/involve]
> [a [xxx-type] gc] [distribution] [etc] [...],
> [declare that], [use some heuristics], [else be hand-tuned].
> [...] [a GC construction kit].
   Here we go with a more or less specialized meta GC!

> I think my idea is essentially the same thing as Francois-Rene Rideau's
> "meta gc", but meta-gc sounds more grandiose than just a few interfaces,
> where one can plug in different compatible components.
   Yup. Happy to see my message wasn't trashed to /dev/null.

> Plug
> compatibility also offers the benefit of easy experimentation -- one can
> try out different gc's with different applications, to see what works
> well in practice.
   That's also what I pinned out.

> Any thinking on the issue of mixing and matching parts of gc algorithms?
   Maybe *we* should join and start (yet another) project ?
   But in any case, we need proficient compiler-writers in the team,
if we want any result in reasonable time.

> - Bob
   Regards to all the finest people on GClist.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW page at URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"