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:50:11 GMT
Here appears a nice pre-GSoC task:
1) justify that USE_32BITS_HASHCODE path is used by placing assert(0
&& "USE_32BITS_HASHCODE is used") at [2];
2) remove the macro and the dead path in the code to make
understanding possible.

Since we need one specific release to pass all benchmarks, there
hardly exists a performance use case for 7-bit hash codes, doesn't it?


On Fri, Feb 20, 2009 at 9:34 AM, 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/
>



-- 
С уважением,
Алексей Федотов,
http://people.apache.org/~aaf/

Mime
View raw message