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.



> Am 29.04.2016 um 19:14 schrieb Jochen Theodorou <blackd...@gmx.org>:
> 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 
> <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 <blackd...@gmx.org 
>>> <mailto:blackd...@gmx.org>
>>> <mailto:blackd...@gmx.org <mailto:blackd...@gmx.org>>>:
>>> On 29.04.2016 13:19, Michael Haupt wrote:
>>>> Hi Jochen,
>>>>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou <blackd...@gmx.org 
>>>>> <mailto:blackd...@gmx.org>
>>>>> <mailto:blackd...@gmx.org <mailto:blackd...@gmx.org>>
>>>>> <mailto:blackd...@gmx.org <mailto:blackd...@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


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

Reply via email to