[gclist] Finalizers & Reference counting.
Fri, 30 Aug 2002 10:59:14 -0400 (EDT)
There's also the Older-First GC work from the DaCapo project that might be
On Fri, 30 Aug 2002, Josef Svenningsson wrote:
> 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
> 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
|\ _,,,---,,_ email@example.com
ZZZzz /,`.-'`' -. ;-;;,_ firstname.lastname@example.org
|,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