hg: mlvm/mlvm/jdk: cval: hang caches on classes

[John Rose]

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: mov	ecx, [edx+0x60]  ;*getfield Class.classValueCache : Entry[]
  M2: mov	ebp, [ecx+0x8]   ;*arraylength
      {mov esi, ebp; dec esi}
  M3: and	esi, [eax+0x8]   ;*iand ClassValue.hashCodeForCache
      {cmp esi, ebp; jnc (slow)}
  M4: mov	ecx, [ecx+esi*4+0xC]  ;*aaload : Entry
      {implicit cmp ecx, 0; jz (slow)}
  M5: mov	esi, [ecx+0x8]   ;*getfield WeakReference.referent : ClassValue$Version
  M6: mov	ebp, [eax+0xC]   ;*getfield ClassValue.version : ClassValue$Version
      {cmp esi, ebp; jnz (slow)}
  M7: mov	eax, [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.rose at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20110804/19230991/attachment.html