hg: mlvm/mlvm/jdk: cval: hang caches on classes
Charles Oliver Nutter
headius at headius.com
Thu Aug 4 01:43:01 PDT 2011
I see there's WeakReference used in there...will ClassValue have
WeakReference-like impact on GC?
I'll try to get JRuby using ClassValue for a few things soon, to help
test this out against non-ClassValue solutions.
- Charlie
On Thu, Aug 4, 2011 at 1:21 AM, John Rose <john.r.rose at oracle.com> 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: 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
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
More information about the mlvm-dev
mailing list