harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yuan Zhang <trojany...@gmail.com>
Subject Re: [drlvm][gc] What does an Partial_Reveal_Object object represents in GarabageCollector?
Date Mon, 23 Feb 2009 01:26:59 GMT
Thanks for all of you, I think I have known the real problem.
Best regards
2009/2/21 Xiao-Feng Li <xiaofeng.li@gmail.com>

> Right, the 7-bit hashcode solution is virtually removed. It has
> serious performance issue with applications requiring a large set of
> hash values.
>
> Back to the VM/GC interface, hashcode was considered to be part of VM
> Core functionality. Then we agreed that it is more appropriate to
> consider hashcode as part of GC functionalities.  This is why we have
> that legacy code in VMcore.
>
> Thanks,
> xiaofeng
>
> On Fri, Feb 20, 2009 at 2:34 PM, Alexei Fedotov
> <alexei.fedotov@gmail.com> wrote:
> > Hello Yuan,
> >
> > Let me try to answer the question. I believe the current
> > implementation uses USE_32BITS_HASHCODE to make hash tables work
> > efficiently. In this case the hash code, when attached, is placed in
> > memory right after all object fields. See the following at [2]:
> >
> >>  else if (infoMask == HASHCODE_SET_ATTACHED)     hash = *(int*)
> ((unsigned char *)p_obj + vm_object_size(p_obj));
> >
> > When Ivan used shorter 7-bit hashes in the stop the world collector,
> > he probably restored hash values after live objects were marked - that
> > made possible reusing the same space for both things: hashes and mark
> > bits.
> >
> > You can learn more from Xiao Feng or [1].
> >
> > [1]
> http://www.google.com/codesearch/p?hl=en#TasP9sO-cIM/trunk/vm/gc_gen/src/common/hashcode.h
> > [2]
> http://www.google.com/codesearch/p?hl=en#TasP9sO-cIM/trunk/vm/gc_gen/src/common/gc_for_vm.cpp&q=HASHCODE_SET_ATTACHED&exact_package=http://svn.apache.org/repos/asf/harmony/enhanced/drlvm/
> >
> >
> > On Fri, Feb 20, 2009 at 4: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/> <
> >>> http://people.apache.org/%7Eaaf/>
> >>> >>
> >>> >
> >>>
> >>
> >
> >
> >
> > --
> > С уважением,
> > Алексей Федотов,
> > http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/>
> >
>
>
>
> --
> Managed Runtime Technology Center, Intel
>

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