ClassValue perf?

[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 <blackdrag at gmx.org
>> <mailto:blackdrag at gmx.org>>:
>> On 29.04.2016 13:19, Michael Haupt wrote:
>>> Hi Jochen,
>>>
>>>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou <blackdrag at gmx.org
>>>> <mailto:blackdrag at gmx.org>
>>>> <mailto:blackdrag at gmx.org>>:
>>>> 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
>
> --
>
> Oracle <http://www.oracle.com/>
> 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 <http://www.oracle.com/commitment>	Oracle is committed to
> developing practices and products that help protect the environment
>
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>