Not sure to understand the full patch,
anyway nextHashCode should be declared final.
regards,
Rémi
On 08/04/2011 10:21 AM, John Rose wrote:
Benchmarks indicate a 4x speedup from previous implementation.
The fast path has 7 memory references. Here's what it looks like:
{mov eax, (cval : ClassValue); mov edx, (type : Class)}
M1: movecx, [edx+0x60] ;*getfield Class.classValueCache : Entry[]
M2: movebp, [ecx+0x8] ;*arraylength
{mov esi, ebp; dec esi}
M3: andesi, [eax+0x8] ;*iand ClassValue.hashCodeForCache
{cmp esi, ebp; jnc (slow)}
M4: movecx, [ecx+esi*4+0xC] ;*aaload : Entry
{implicit cmp ecx, 0; jz (slow)}
M5: movesi, [ecx+0x8] ;*getfield WeakReference.referent :
ClassValue$Version
M6: movebp, [eax+0xC] ;*getfield ClassValue.version :
ClassValue$Version
{cmp esi, ebp; jnz (slow)}
M7: moveax, [ecx+0x18] ;*getfield value
{mov (result : T), eax}
That's probably good enough for most uses.
All of the memory references are possible CSE and loop invariants.
I saw a too-simple benchmark loop collapse completely to constant time.
The range check (of the form a[a.length-1 & i]) could be simplified
with a little work.
The version check defends against ClassValue.remove.
Maybe it could be removed by push notification, but it's probably not
worth it.
-- John
On Aug 3, 2011, at 9:58 PM, john.r.r...@oracle.com
<mailto:john.r.r...@oracle.com> wrote:
Changeset: c26fceff6309
Author: jrose
Date: 2011-08-03 21:57 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/c26fceff6309
cval: hang caches on classes
+ cval-tune-7030453.patch
! series
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
