Thanks for all of you, I think I have known the real problem. Best regards 2009/2/21 Xiao-Feng Li <[email protected]>
> 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 > <[email protected]> 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 <[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/%7Eaaf/> > >>> >> > >>> > > >>> > >> > > > > > > > > -- > > С уважением, > > Алексей Федотов, > > http://people.apache.org/~aaf/ <http://people.apache.org/%7Eaaf/> > > > > > > -- > Managed Runtime Technology Center, Intel >
