harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chunrong lai <chunrong...@gmail.com>
Subject Re: [drlvm][gc] What does an Partial_Reveal_Object object represents in GarabageCollector?
Date Fri, 20 Feb 2009 09:15:19 GMT
hi, Yuan:
    Let me try to answer the question.
    (1) A Partial_Reveal_Object* actually refers to a ManagedObject* but
only explicitly presents the object header of the object ("partial_reveal"
means "header"). If you read the GC source code, scan_object() will
basically touch the whole object.
    (2) There are conventions between VM and GC about which object_info bits
are VM bits (for synchronizations etc) and which bits are GC bits(for
marking, hashcode identification). VM decides how to use VM bits in
Object_info but does not touch the GC bits. GC can use GC bits internally as
it like and also does not touch VM bits.
    (3) It is hard to say if a modification to ManagedObject declaration
requires change to Partial_Reveal_Object declaration or not. If you change
the object header length, of course you need to change GC or GC can not scan
the updated object. If you just change the VM bits of the object_info field,
GC does not care about that. If you change GC bits of object_info in VM it
will be very tricky for GC to adopt the change.
    (4) Another convention between the GC and VM is the Vtable organization.
GC regards it as a "Partial_Reveal_VTable" since GC is only concerned with
the the first 3 fields. Other fields are revealed in VM while VM only regard
the first field as _gc_private_information and never use it.

On Fri, Feb 20, 2009 at 9:21 AM, Yuan Zhang <trojanyuan@gmail.com> wrote:

> I have noticed that the least 10 significant bit of obj_info field in
> struct
> ManagedObject is used to store hashcode of a ManagedObject, but it seems
> that gc use the least 8 significant bit to store some gc-concerned
> information such as mark-bit, I wonder if this may cause problems? Because
> I
> have little knowledge of the usage of hashcode in the ManagedObject.
>
> 2009/2/20 Pavel Pervov <pmcfirst@gmail.com>
>
> > This is the data interface between the VM and a GC. GC must know some
> > details of object layout in the heap to be able to implement
> > collection algorithms efficiently.
> >
> > Pavel.
> >
> > On Thu, Feb 19, 2009 at 3:57 PM, Yuan Zhang <trojanyuan@gmail.com>
> wrote:
> > > Alexei,
> > > Thanks for your answer. Can I understand this problem in this way:
> > >     -----at the current edition of harmony, an Partial_Reveal_Object
> > > pointer is just casted from a ManagedObject pointer, and the purpose of
> > the
> > > duplicate declaration of the struct is to minimize dependency between
> gc
> > and
> > > vmcore because in the future the two structs may have different
> > > declarations.
> > >
> > > 2009/2/19 Alexei Fedotov <alexei.fedotov@gmail.com>
> > >
> > >> Yuan,
> > >> The intention of this construct is to minimize dependency between gc
> > >> and vmcore limiting interfaces to C-type ones. If you changed layout
> > >> of fields, you should update GC struct. If you only changed vt
> > >> functions, then probably the problem is in other place.
> > >>
> > >> Thanks.
> > >>
> > >> On Thu, Feb 19, 2009 at 3:09 PM, Yuan Zhang <trojanyuan@gmail.com>
> > wrote:
> > >> > I have found that the declaration of struct ManagedObject and the
> > >> > declaration of struct Partial_Reveal_Object are alomost the same.
> The
> > >> only
> > >> > difference is that struct ManagedObject is used in vmcore, and
> struct
> > >> > Partial_Reveal_Object is used in gc, so I have a question: "Does a
> > >> > Partial_Reveal_Object pointer in gc always points to an
> ManagedObject
> > >> object
> > >> > in vmcore?". Because I have modified the declaration of struct
> > >> ManagedObject
> > >> > for some purpose, so if the answer to my question is "yes", I also
> > have
> > >> to
> > >> > modify other codes to make gc run right?
> > >> >
> > >> > I appreciated any help from you!
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> С уважением,
> > >> Алексей Федотов,
> > >> http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/>
<
> > http://people.apache.org/%7Eaaf/>
> > >>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message