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 



> 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


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