Aha, so it's literally no way to disable buffered hashcode? That means identityHashCode GC helper can't be implemented as magic.
That's too bad, my profiling and measurements shows that identityHashCode computation is really hot on serialization workload and I'm pretty sure the same picture shows up on any IdentityHashMap user. Simple substitution of GC call in VMMemoryManager.getIdentityHashCode with ((jint)jobj->object >> 2) gives +20% boost to serialization benchmark even with JNI overhead in place. Thanks, Aleksey. On Fri, May 16, 2008 at 3:42 AM, Xiao-Feng Li <[EMAIL PROTECTED]> wrote: > Aleksey, "attached hashcode" works together with "buffered hashcode". > "Buffered hashcode" is created in compacting GC (in other words, in > major collection). So if normally there is few major collections, > there will be very few buffered hashcodes created. In minor > collections, it uses the attached hashcode. > > Thanks, > xiaofeng > > On Fri, May 16, 2008 at 5:06 AM, Aleksey Shipilev > <[EMAIL PROTECTED]> wrote: >> Hi, Xiao Feng, GC gurus, >> >> I'm back to IdentityHashCode implementation on magics [1]. I had >> managed to inline the helper for System.identityHashCode(), but >> unfortunately I had stuck with buffered hashcode scheme. Basically, >> there is no support for buffered hashcodes in GCHelper and I doubt it >> could be implemented there as we need to traverse native data >> structure on hashcode lookup. Not saying about performance when there >> are many hashcodes in the run, I have a suspicion there is the problem >> too. >> >> So I wonder whether is it possible to turn on "attached hashcode" >> instead of "buffered hashcode" somehow to see the performance impact? >> I searched through sources and it's still unclear for me. >> >> Thanks, >> Aleksey. >> >> [1] https://issues.apache.org/jira/browse/HARMONY-5713 >> > > > > -- > http://xiao-feng.blogspot.com >
