Re: ClassValue perf?

2016-04-29 Thread Jochen Theodorou 

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

Re: ClassValue perf?

2016-04-29 Thread Remi Forax 
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 

- Mail original -

> De: "Michael Haupt" 
> À: "Da Vinci Machine Project" 
> 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 >:
> 
> > 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
> 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

> 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

Re: ClassValue perf?

2016-04-29 Thread Michael Haupt 
Hi Jochen,

> Am 29.04.2016 um 14:42 schrieb Jochen Theodorou :
> On 29.04.2016 13:19, Michael Haupt wrote:
>> Hi Jochen,
>> 
>>> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou >> >:
>>> 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

-- 

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

Re: ClassValue perf?

2016-04-29 Thread Jochen Theodorou 



On 29.04.2016 13:19, Michael Haupt wrote:

Hi Jochen,


Am 29.04.2016 um 12:17 schrieb Jochen Theodorou 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?

bye Jochen


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: ClassValue perf?

2016-04-29 Thread Michael Haupt 
Hi Jochen,

> Am 29.04.2016 um 12:17 schrieb Jochen Theodorou :
> 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 
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
  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

Re: ClassValue perf?

2016-04-29 Thread Jochen Theodorou 



On 29.04.2016 10:28, Michael Haupt wrote:

All,

see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what
is currently available.

We have three patches:
* Christian's, which simply reduces the HashMap size,
* Peter's, which refactors ClassValueMap into a WeakHashMap,
* mine, which attempts to introduce the single-value storage
optimization John had suggested (I worked on performance with Aleksey -
thanks!).

All of these are collected in the patches subdirectory for convenience.
(Peter, I adapted your patch to the new Unsafe location.)

I extended Peter's benchmark (thanks!) to cover single-value storage;
the source code is in the benchmark subdirectory, together with raw
results from running the benchmark with each of the three patches
applied. A results-only overview is in benchmark-results.txt.

The three are roughly on par. I'm not sure the single-value storage
optimization improves much on footprint given the additional data that
must be kept around to make transition to map storage safe.

Opinions?


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

bye Jochen

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: ClassValue perf?

2016-04-29 Thread Michael Haupt 
All,

see http://cr.openjdk.java.net/~mhaupt/8031043/ for a snapshot of what is 
currently available.

We have three patches:
* Christian's, which simply reduces the HashMap size,
* Peter's, which refactors ClassValueMap into a WeakHashMap,
* mine, which attempts to introduce the single-value storage optimisation John 
had suggested (I worked on performance with Aleksey - thanks!).

All of these are collected in the patches subdirectory for convenience. (Peter, 
I adapted your patch to the new Unsafe location.)

I extended Peter's benchmark (thanks!) to cover single-value storage; the 
source code is in the benchmark subdirectory, together with raw results from 
running the benchmark with each of the three patches applied. A results-only 
overview is in benchmark-results.txt.

The three are roughly on par. I'm not sure the single-value storage 
optimisation improves much on footprint given the additional data that must be 
kept around to make transition to map storage safe.

Opinions?

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