ClassValue perf?

[Michael Haupt]

Hi Peter,

thank you for chiming in again! :-) I'll look at this in depth on Friday.

Best,

Michael

> Am 04.05.2016 um 17:50 schrieb Peter Levart <peter.levart at gmail.com>:
> 
> Hi,
> 
> On 04/29/2016 10:28 AM, Michael Haupt wrote:
>> All,
>> 
>> see http://cr.openjdk.java.net/~mhaupt/8031043/ <http://cr.openjdk.java.net/%7Emhaupt/8031043/> for a snapshot of what is currently available.
>> 
>> We have three patches:
>> * Christian's, which simply reduces the HashMap size,
>> * Peter's, which refactors ClassValueMap into a WeakHashMap,
>> * mine, which attempts to introduce the single-value storage optimisation John had suggested (I worked on performance with Aleksey - thanks!).
>> 
>> All of these are collected in the patches subdirectory for convenience. (Peter, I adapted your patch to the new Unsafe location.)
>> 
>> I extended Peter's benchmark (thanks!) to cover single-value storage; the source code is in the benchmark subdirectory, together with raw results from running the benchmark with each of the three patches applied. A results-only overview is in benchmark-results.txt.
>> 
>> The three are roughly on par. I'm not sure the single-value storage optimisation improves much on footprint given the additional data that must be kept around to make transition to map storage safe.
>> 
>> Opinions?
> 
> I must admit that my old patch is very complex, so I doubt anyone will take time to review it. It is almost a clean-room re-implementation of ClassValue API. My main motivation was footprint optimization for all sizes - not just one value per class as I doubt this will be very common situation anyway. Current ClassValue maintains 2 parallel hash-tables per class. A WeakHashMap which is accessed with proper synchronization and an optimized "cache" of entries for quick access. This makes it consume almost 100 bytes per (Class, ClassValue) pair. I managed to almost half the overhead for typical situation (1024 classes x 16 ClassValue(s)), but for the price of complexity.
> 
> Reviving this thread made me think about ClassValue again and I got another idea. This is an experiment to see if ConcurrentHashMap could be leveraged to implement ClassValue API with little added complexity:
> 
>     http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.01/ <http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.01/>
> 
> And here are the results of a benchmark comparing JDK 9 original with this alternative:
> 
>     http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/ClassValueBench.java <http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/ClassValueBench.java>
> 
> It is a little slower for random access of bigger sizes and #s of classes. Most probably a consequence of reduced cache hit ratio as CHM is a classical hash table with buckets implemented as linked list of entries whereas jdk 9 ClassValue cache is a linear-scan hash table which has better cache locality. This is particularly obvious in sequential access where CHM behaves on-par. It's a pity that CHM has a non-changeable load factor of 0.75 as changing this to 0.5 would most certainly improve benchmark results for a little more memory.
> 
> Where this version excels is in footprint. I managed to more than half the overhead. There's only a single ReferenceQueue needed and consequently expunging of stale data is more prompt and thorough. The code of ClassValue has been more than halved too.
> 
> What do you think?
> 
> Regards, Peter


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160504/c509432d/attachment.html>