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 <[email protected]> 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 <[email protected]> > >> 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 <[email protected]> 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 <[email protected]> >> > >> >> 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 <[email protected]> >> 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/
