harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Xiao-Feng Li <xiaofeng...@gmail.com>
Subject Re: [drlvm][gc] What does an Partial_Reveal_Object object represents in GarabageCollector?
Date Sat, 21 Feb 2009 11:29:47 GMT
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/~aaf/
>



-- 
Managed Runtime Technology Center, Intel

Mime
View raw message