harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: [drlvm][gc] What does an Partial_Reveal_Object object represents in GarabageCollector?
Date Fri, 20 Feb 2009 06:34:46 GMT
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/

Mime
View raw message