You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Alexei Fedotov <al...@gmail.com> on 2009/02/19 13:23:03 UTC
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
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 <tr...@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/
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Alexei Fedotov <al...@gmail.com>.
Yes, I think so. It would be nice to get Xiao Feng's confirmation of this.
On Thu, Feb 19, 2009 at 3:57 PM, Yuan Zhang <tr...@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 <al...@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 <tr...@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/
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by chunrong lai <ch...@gmail.com>.
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 <tr...@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 <pm...@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 <tr...@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 <al...@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 <tr...@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/>
> > >>
> > >
> >
>
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Alexei Fedotov <al...@gmail.com>.
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
<al...@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 <tr...@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 <pm...@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 <tr...@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 <al...@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 <tr...@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/
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Yuan Zhang <tr...@gmail.com>.
Thanks for all of you, I think I have known the real problem.
Best regards
2009/2/21 Xiao-Feng Li <xi...@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
> <al...@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 <tr...@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 <pm...@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 <tr...@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 <al...@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 <tr...@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
>
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Xiao-Feng Li <xi...@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
<al...@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 <tr...@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 <pm...@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 <tr...@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 <al...@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 <tr...@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
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Alexei Fedotov <al...@gmail.com>.
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 <tr...@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 <pm...@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 <tr...@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 <al...@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 <tr...@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/
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Yuan Zhang <tr...@gmail.com>.
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 <pm...@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 <tr...@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 <al...@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 <tr...@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/>
> >>
> >
>
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Pavel Pervov <pm...@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 <tr...@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 <al...@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 <tr...@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/>
>>
>
Re: [drlvm][gc] What does an Partial_Reveal_Object object represents
in GarabageCollector?
Posted by Yuan Zhang <tr...@gmail.com>.
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 <al...@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 <tr...@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/>
>