Re: ClassValue perf?

[Peter Levart]

Hi,


On 04/29/2016 10:28 AM, Michael Haupt wrote:

All,

see http://cr.openjdk.java.net/~mhaupt/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/

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

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



Best,

Michael

--

Oracle 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
OracleJava 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
Green Oracle  	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


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: ClassValue perf?

[Michael Haupt]

Hi again,

I've uploaded a reformatted results file (and an Excel sheet in case that's 
interesting) that show the results side by side.

Best,

Michael

> Am 02.05.2016 um 10:38 schrieb Michael Haupt :
> 
> Hi Jochen,
> 
> thanks for clarifying. I've added results from running the benchmarks on an 
> the unpatched JDK 9 base (see the CR link). The twisti and plevart patches 
> perform better for large numbers of classes and class values; the mhaupt 
> patch is weaker than the baseline in those settings.
> 
> As pointed out in my reply to Rémi, I'm very much in favour of using 
> Christian's patch too.
> 
> Best,
> 
> Michael
> 
>> Am 29.04.2016 um 19:14 schrieb Jochen Theodorou > >:
>> 
>> Hi,
>> 
>> there was not really any misunderstanding, just that some optimizations have 
>> to be considered carefully. I am no JDK reviewer, so I can give only my 
>> opinion as a user. But I am missing a comparison with the unpatched version. 
>> Comparing the given results and considering the size of the patches and that 
>> they might have to be reconsidered later on would lead me to prefer the 
>> twisti version actually. But since I am missing the compare with the 
>> unpatched version I cannot really judge the performance penalty a resize of 
>> the map will without doubt introduce. 
>> http://cr.openjdk.java.net/~mhaupt/8031043/benchmark/ClassValueBench.java 
>>  
>> contains some numbers, but I cannot tell if they compare or not. At least it 
>> does not contain the numbers I would expect
>> 
>> bye Jochen
>> 
>> On 29.04.2016 15:21, Michael Haupt wrote:
>>> Hi Jochen,
>>> 
 Am 29.04.2016 um 14:42 schrieb Jochen Theodorou >>> 
 >>:
 On 29.04.2016 13:19, Michael Haupt wrote:
> Hi Jochen,
> 
>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou > 
>> >
>> >>:
>> my fear is a bit that having only a single value, will not be enough
>> if you have for example multiple dynamic languages running... let's
>> say Nashorn, JRuby, and Groovy. Also, if I ever get there, using
>> multiple values would become a normal case in Groovy.
>> 
>> So any size depending optimization looks problematic for me
> 
> I may misunderstand you here - note the patch does not introduce a
> single-value *only* ClassValue. The patch is meant to introduce a
> special case for as long as there is only one value associated with a
> class. As soon as a second value comes in, the ClassValue will
> transition to the usual map storage.
> 
> Please let me know if this is a response to your concern.
 
 how does performance compare to cases of 2-12 values?
>>> 
>>> OK, I'm still not sure if there was a misunderstanding or not, and
>>> whether my response has clarified that. Please let me know.
>>> 
>>> To answer your question, see the numbers reported in
>>> http://cr.openjdk.java.net/~mhaupt/8031043/bench-results.txt 
>>>  - I'm not
>>> going to quote them in full detail here, but overall the numbers for 2,
>>> 4, and 16 values are on par for the randomGenerator and
>>> sequentialGenerator benchmarks, and show slightly better performance (on
>>> the order of 1ns) for the twisti and plevart patches.
>>> 
>>> Best,
>>> 
>>> Michael


-- 

 
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
  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

Re: 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 :
> 
> Hi,
> 
> On 04/29/2016 10:28 AM, Michael Haupt wrote:
>> All,
>> 
>> see http://cr.openjdk.java.net/~mhaupt/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/ 
> 
> 
> 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
>  
> 
> 
> 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


-- 

 
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
  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