[gclist] gc interface

[Francois-Rene Rideau]

Re: meta-gc, plug compatible gc's, etc.

> Here's a somewhat different opinion on the issue:
>
> [Null GC as the simplest case]
   Surely, a meta-GC could formalize GC's
according to their common identical semantics,
and to their "performance constraints",
such as speed, code and data memory consumption, etc.

> [Danger of bugs that spread with combining GC submodules]
   That's precisely why I envision a generic meta-GC only as developped
with formal methods that ensure that everything works as specified.

> [Incompatibilities of interface between GCs]
   Well, surely some hassle is involved, which could be mostly automated,
in writing low-level code that matches any of many GCs,
GC control being the least of incompatibility problems.
But you can't have what you don't give, either.

> - Things get much worse if you allow multiple gc's for different program
> modules.
   Again, formal methods may prove necessary.

> Doing this safely, in such a way that you can handle cross module
> cycles without performance anomalies is hard.
   I believe you, though with no experience.

> The only measured performance
> improvements I've seen are from systems that sacrifice safety.
   Then I'm not sure these are "improvements".

> As far as I cans tell it gets considerably harder
> still if you expect to be able to recover from
> running out of memory, at least most of the time.
   I seemingly didn't understand how catastrophic it could be
to run out of memory!


> I've seen no reasonable
> solution to that problem.
> (Even writing mark procedures for our collector is
> more of a black art than I would like.
> Some of that has to do with the next
> point.)
As for running out of memory,
I seemingly didn't understand how catastrophic it could be.
It seems to me that depending on the language, environement, etc,
an exception/roll-back mechanism, could handle all situations calmly.

> - We all prefer to discuss interesting algorithms rather than ugly
> bit-twiddling.  But a lot of the performance of a collector, at least in my
> experience, depends on low level implementation details, and constant factors
> in the implementation.  Such considerations often outweigh higher level
> algorithmic considerations.  It's harder to get these simultaneously right for
> a number of interacting implementations.
   This is why I said that
the high-level formal language needs to express low-level constraints,
and why no available formal language seems possible to use.

--    ,        	                                ,           _ 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/"