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 <[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/~aaf/ > -- С уважением, Алексей Федотов, http://people.apache.org/~aaf/
