[gclist] Re: identifying clusters of objects

[David Petrie Stoutamire]

> We are noting that objects are born in clusters
> and die in clusters. For example a program may
> build a table and in doing so create a lot of
> objects which will live until the whole table
> dies.
> 
> It seems that the programmer must know about this
> and could say.
>    gcBuildingSomething("FooBarTable");
>    // build the table
>    gcDoneBuildingSomething("FooBarTable");
> 
> And the collector could form very good generational
> ideas instead of simply guessing.
> 
> Another way would be to annotate how long lived
> something is.
> 
> aFun()
> {
>         foo *f = newLifeInfo aFun foo;
>         ...
>         ...
> }
> 
> The newLifeInfo aFun foo is like new foo but says
> this object's usefull life will be about as long
> as aFun lives. Oh ... something like that.

My thesis work (it will be available in about two months) proposes a
language construct which is similar.  Objects and threads are grouped in
an explicit runtime hierarchy.  The compiler and runtime take these
annotations and map them onto the available hardware to achieve good
locality and thread scheduling.  This enables high performance and
portability at the same time across a variety of machines, from serial
processors with many levels of cache to ccNUMA to distributed with
compiler-generated messaging.

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.

    - Dave

--
David Stoutamire
http://www.icsi.berkeley.edu/~davids