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




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,

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

Reply via email to