Re: Finalizers & Reference counting.

There's also the Older-First GC work from the DaCapo project that might be
relevant:  http://www-ali.cs.umass.edu/McKinley/garbage.html
	Igor

On Fri, 30 Aug 2002, Josef Svenningsson wrote:

> Jerry,
>
> I suggest taking a look at "regions" which is an alternative memory
> management strategy which works roughly as you outlined. Regions have been
> successfully used in the ML Kit compiler. I won't go into the details of
> how regions works but instead refer to the home page of the ML Kit
> compiler:
>
> http://www.itu.dk/research/mlkit/index.html
>
> Cheers,
>
> 	/Josef
>
>
> On Fri, 30 Aug 2002, Jerrold Leichter wrote:
>
> > This whole discussion does bring up an interesting point, however.  Some
> > programs - compilers are a great example - go through phases with the
> > property that:
> >
> > 	a)  Each phase allocates and manipulates a significant amount of
> > 		memory, much of which remains live throughout the phase;
> >
> > 	b)  Much of the memory allocated in a phase goes dead when the
> > 		phase ends.
> >
> > (In many cases, the "much" memory is actually identifiable at the point of
> > allocation.)
> >
> > The classic method to deal with this in a non-GC environment is to support
> > the notion of an allocation domain (various name have been used for this).
> > Each phase creates an AD, and phase-specific memory is allocated from the
> > AD.  At the end of the phase, the entire AD is deleted, normally using a
> > fast mechanism that is often essentially independent of the number of
> > allocated blocks in the AD.  In a very simple case, an AD is a block of
> > contiguous memory, allocations just "bump the pointer", and deleting an AD
> > simply requires deleting the large block, ignoring its content.  This can be
> > surprisingly effective if AD-allocated memory is rarely deleted within the
> > phase.  (It also helps cache/working set locality.)
> >
> > The question is:  How could you capture the same advantages in a GC'ed
> > system?  It seems that AD's, in some ways, are similar to generations.
> > However, generations have the wrong lifetime semantics:  Anything we would
> > likely have put into an AD will probably get promoted to a generation that
> > will stick around for long after the phase ends.  Still, the basic
> > *techniques* used to implement generational collection could perhaps be used
> > here.
> >
> > Thus, imagine that, in a GC'ed system, we retain the same three user
> > visible primitives:
> >
> > 	ad <- createAD()
> > 	pointer <- allocate(size,ad)
> > 	destroy(ad)
> >
> > We would like destroy() to be fast, as immediate as possible, but of course
> > safe.  If we maintain the invariant that no pointer to an object in an
> > AD can come from outside the AD, then destroy() becomes trivial - just put
> > everything in the AD - or the whole AD, if you allocate it as a big chunck -
> > on the free list.  This should be implementable with write barriers.  (There
> > are, of course, subtleties like allowing register and stack pointers to
> > *not* force stuff out of the AD, or everything will wander out of it rapidly.)
> >
> > I'm sure a complete design and implementation would reveal all kinds of
> > issues.  Has anyone ever looked at this kind of "hinted" GC?
> >
> > 							-- Jerry

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		[email protected]
ZZZzz /,`.-'`'    -.  ;-;;,_		[email protected]
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

It took the computational power of three Commodore 64s to fly to the moon.
It takes a 486 to run Windows 95.  Something is wrong here. -- SC sig file