harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [DRLVM][VM] -- which header bits are available for GC mark and GC forwarding use?
Date Fri, 25 Aug 2006 15:38:06 GMT
On 8/25/06, Andrey Chernyshev <a.y.chernyshev@gmail.com> wrote:
> On 8/25/06, Weldon Washburn <weldonwjw@gmail.com> wrote:
> > On 8/24/06, Salikh Zakirov <Salikh.Zakirov@intel.com> wrote:
> > > In any way, currently there is no single header file in the system,
> > > which would describe the object structure. Rather, DRLVM uses some
> > > static assumptions about object header, which are not enforced by any
> > > common include file. This would be a nice thing to solve...
> >
> > Good point.  There needs to be a discussion on harmony-dev regarding
> > how the object header bits are "sliced and diced".  From talking to
> > the MMTk guys (Steve Blackburn) it seems MMTk wants to have one byte
> > of object header for private use.  Its unclear to me if this will be a
> > performance problem for a product JVM.  I think the hashCode can be
> > reduced to one bit plus the object's current address at first
> > HashCode() invocation.  I'd put this hash bit in the GC byte.  And
>
> OK, then what this one bit will be used for? Where do we keep the hash
> code after the object is moved and it's address is changed? Perhaps
> I'm not getting the idea...

Hashcode for the moved object can be allocated just after the end of
the object. This is done in GC v4.1 (HARMONY-1269). For more details
how it can be done, look at my previous posting in this thread.

The problem is, that changes required for existing algorithms to use
this approach. E.g. it is not so easy to do this in Gc_v4. So, use of
GC interface function gc_get_hashcode() can help. Some of algorithm
may store hashcode in object info bits, others can use more advanced
approaches.

>
> > make the GC byte the lowest byte in the header word.  The remaining
> > 3bytes could be used for fat/thin locks.  Are there any remaining
>
> I think this is a good idea to use the different bytes for GC and
> Object's monitor purposes. It can help monitor's and GC's algorithms
> to work independently and avoid extensive atomic operations whenever
> it is possible.
>
> Thanks,
> Andrey.

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message