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