Hi Rémi, thanks for your reply - note that my patch is merely the result of an effort to meet the requirement of making the single-value storage suggested in the discussion on https://bugs.openjdk.java.net/browse/JDK-8031043 fast. This appears to be difficult. I agree that the performance isn't good enough to warrant integrating this code, especially given the complexity.
In fact, I think the obvious solution (reducing the initial hash table size to 2) should be chosen. It introduces no performance penalty, reduces footprint, and otherwise leaves the complex code untouched. Thanks for pointing out the oddity in removeSingleEntry - this I overlooked in one of the refactorings. :-) BTW the VarHandles implementation is on the way to not needing ClassValue any more. Best, Michael > Am 29.04.2016 um 17:32 schrieb Remi Forax <fo...@univ-mlv.fr>: > > Hi Mickael, > the experience has proven that the code of ClassValue is hard to get right, > adding any optimization into such code will make it more complex, less > readable, more error prone so any optimization introduced as to really worth > it. > I may have not correctly read the perf number, but IMO it's not enough. > > The other problem is that ClassValue is currently used by the implementations > of method handles and var handles and may be used by several other classes in > the future, so the optimization is/will not be very reliable. > > I've not seriously review your patch but the first two lines of > removeSingleEntry seems rather mysterious. > > cheers, > Rémi > > De: "Michael Haupt" <michael.ha...@oracle.com> > À: "Da Vinci Machine Project" <mlvm-dev@openjdk.java.net> > Envoyé: Vendredi 29 Avril 2016 13:19:32 > Objet: Re: ClassValue perf? > > Hi Jochen, > > Am 29.04.2016 um 12:17 schrieb Jochen Theodorou <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. > > 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 mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
