[gclist] Re: gclist-digest V1 #130
David Petrie Stoutamire
davids@ICSI.Berkeley.EDU
Tue, 10 Dec 1996 13:03:46 -0800 (PST)
> >While allocation and GC are expected to take advantage of this clustering
> >information to improve locality, I don't specifically explore the ways GC
> >could exploit this information in the form of object lifetimes, tenuring,
> >etc. (I do allow explicit deallocation of entire clusters in one gulp.)
> >It's a good idea though.
>
> So do you have a postscript file or something yet. You might get out some
> ideas on connection to GC Or is it too late? Garbage collection doesn't
> allow explicit deallocation of anything so we don't fit your thesis that
> way.
I didn't mean to imply that my system doesn't have garbage collection. It
does, and it is pretty fundamental to my work. I meant that while I'm
exploring having allocation exploit clustering annotations provided by the
programmer, I'm not attempting to exploit other information that these
annotations may provide such as expected lifetime. That's future work.
Garbage collection does allow explicit deallocation; in fact, they
complement nicely. At worst, deallocation can be a hint the GC can throw
away. But another use is instead of actually deallocating, explicit
deallocations can be used as a checkable assertion that there will be no
more accesses to an object. The Sather system supports these modes of
use. (In a kludgier sense, C+Purify does too.) Typically one develops
compiling such that deallocations are treated as assertions and then
switches to true deallocation only for trusted code.
One thing I bring up in my thesis that I haven't seen elsewhere is a nasty
interaction between weak consistency models and explicit deallocation.
(In a nutshell: explicit deallocation allows addresses to be reused for
different objects, but weak consistency hardware can't know this. So
under some circumstances explicit deallocation has to explicitly flush
remote copies of the dead object, which isn't always possible under eg.
acquire-release.)
- Dave
--
David Stoutamire
http://www.icsi.berkeley.edu/~davids