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.lev...@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
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
