Copyable GC

[Alexandre Oliva]

On Apr  1, 1999, Maxim Kizub <max at immsp.kiev.ua> wrote:

> For 1. We know, that only Class and String
> objects may be referenced from code.

invokestatic and invokespecial instructions also generate code that
refers to gc-able data: the entry point of the JIT-compiled methods.

> It's better to not have direct references to String objects from
> jit-generated native code, but load them indirectly

There's a performance trade-off here, and I'm not sure it's best to
introduce the indirect reference or to prevent such objects from
moving.

> For 3. Object.hashCode() method should return
> the same value for the whole lifecicle of
> object. If we will have ability to optimize memory
> allocation (defragment memory) by object
> copying - we need to find a way to return the same
> value.

Yup.  We may have different pools of objects, one for those whose
identity hashCode has never been computed, and one for the others,
with an additional slot to store the computed hashCode.  An object
would be moved from one pool to the other at the first computation of
its identity hashCode().

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Brasil
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists