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 <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 -- <http://www.oracle.com/> 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 <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment
_______________________________________________ mlvm-dev mailing list firstname.lastname@example.org http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev