ClassValue perf?

[Michael Haupt]

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 <forax at 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.haupt at oracle.com>
> À: "Da Vinci Machine Project" <mlvm-dev at 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 <blackdrag at gmx.org <mailto:blackdrag at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160502/7421d549/attachment.html>