Re: newbie Q: storage management

[jsa@alexandria (Jon S Anthony)]

In article <33740D4A.5BE1@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:

> Jon S Anthony wrote:
> > 
> > In article <33720AA5.2E59@sprintmail.com> "John G. Volan" <johnvolan@sprintmail.com> writes:
> > 
> > > I'm very keen to see how true GC (not conservative GC) could be
> > > shoehorned into Ada95 (other than by compiling to the Java virtual
> > > machine).
> > 
> > Well, if you have compiler support this really should not be that much
> > of an issue.  
> 
> Jon, does this mean that the stuff you're working on involves adding
> some compiler support for GC?

No.  No compiler support.  I've mentioned elsewhere that hacking this
into GNAT would not be a reasonable use of (my) time.


> should have asked the question directly: How exactly are you planning to
> achieve this GC support?  (If the answer is "I'd like to keep my cards
> close to the vest right now until it's done and I get my money for it",
> well, that's cool, but just say so.)

Close to the vest for the moment, but mostly because I do not want to
oversell the case or miss a T-crossing or I-dotting.  I have a couple
variants which are now working, but which I am trying to refine wrt to
both time and space (including reference locality issues and possible
paging concerns and such).  And there are several other variants and
issues to consider (incremental stuff in particular).

Besides, Robert claims there is positively, absolutely, beyond a
shadow of any conceivable doubt, no money in this.  :-) :-)


> Barring compiler support, it's fairly obvious that one could implement
> "smart references" in Ada95 using a Controlled type wrapped around an
> access type.  (Clearly, this is how reference-counting schemes have been
> implemented in Ada95 already.)  The Initialize, Adjust, and Finalize for
> these "smart references" could make sure that every reference registered
> itself with the collector.  I can see that this combined with
> Storage_Pools could provide a complete GC mechanism.  But it would
> require programmer discipline: A programmer would have to make sure to
> always wrap every access value into one of these "smart references." 
> Some potential for human error there.

First, this is just waaaayyyy tooooo expensive in time and space.
Secondly, as you say it is not particularly "safe".  I wanted simple
pointers and safety of use - gurantees of consistency and such - and
have managed to get this except for a pathological case where safety
can be accidently circumvented.  The only way to ensure that this
can't happen would require access to the stack and frame pointers and
that's not portable (which is a prime requirement).


> So from this should I infer that your GC support will exploit type
> information?  Hmm, I figured meta-data would have to come into the
> picture sometime.

Yes - but not in any magical way.


> > > It seems to me that, before you can collect the dead objects in a
> > > given pool, you have to be able to locate and identify every access
> > > value that currently points into that pool.
> > 
> > Yup - you certainly do.
> 
> So is this what your stuff is going tot do?

Absolutely!  All the variants I am considering are tracing collectors
of various sorts - which means you have to have the roots...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com