Re: ClassValue perf?

2016-05-06 Thread Christian Thalinger 

> On May 6, 2016, at 4:48 AM, Michael Haupt  wrote:
> 
> Hi Peter,
> 
> thank you. I've run the full benchmark in my setup and uploaded the updated 
> cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/ 
> .
> 
> The benchmark indeed shows that this latest addition to the group slows down 
> random and sequential access, especially for small numbers of values and 
> classes. The OpenJDK tests are fine; I'm running a batch of internal tests as 
> well.
> 
> Given that one concern with this issue, next to reducing footprint, was to 
> optimise for the single-value case, I'm still a bit hesitant even though the 
> sheer amount of code reduction is impressive. I'll evaluate further.

The main motivation to optimize for the single-value use case is Graal but it’s 
not super important.  Graal solved this issue in a different way and it’s 
questionable Graal would go back using ClassValue so don’t worry too much about 
it.

> 
> Best,
> 
> Michael
> 
>> Am 05.05.2016 um 17:21 schrieb Peter Levart > >:
>> 
>> Hi Michael,
>> 
>> 
>> On 05/04/2016 06:02 PM, Michael Haupt wrote:
>>> Hi Peter,
>>> 
>>> thank you for chiming in again! :-) I'll look at this in depth on Friday.
>> 
>> Good. Because I found bugs in expunging logic and a discrepancy of behavior 
>> when a value is installed concurrently by some other thread and then later 
>> removed while the 1st thread is still calculating the value. Current 
>> ClassValue re-tries the computation until it can make sure there were no 
>> concurrent changes to the entry during its computation. I fixed both things 
>> and verified that the behavior is now the same:
>> 
>> 
>> http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.02/ 
>> 
>> 
>> Regards, Peter
> 
> 
> -- 
> 
>  
> 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-05-06 Thread Michael Haupt 
Hi Peter,

thank you. I've run the full benchmark in my setup and uploaded the updated 
cumulative results to http://cr.openjdk.java.net/~mhaupt/8031043/.

The benchmark indeed shows that this latest addition to the group slows down 
random and sequential access, especially for small numbers of values and 
classes. The OpenJDK tests are fine; I'm running a batch of internal tests as 
well.

Given that one concern with this issue, next to reducing footprint, was to 
optimise for the single-value case, I'm still a bit hesitant even though the 
sheer amount of code reduction is impressive. I'll evaluate further.

Best,

Michael

> Am 05.05.2016 um 17:21 schrieb Peter Levart :
> 
> Hi Michael,
> 
> 
> On 05/04/2016 06:02 PM, Michael Haupt wrote:
>> Hi Peter,
>> 
>> thank you for chiming in again! :-) I'll look at this in depth on Friday.
> 
> Good. Because I found bugs in expunging logic and a discrepancy of behavior 
> when a value is installed concurrently by some other thread and then later 
> removed while the 1st thread is still calculating the value. Current 
> ClassValue re-tries the computation until it can make sure there were no 
> concurrent changes to the entry during its computation. I fixed both things 
> and verified that the behavior is now the same:
> 
> 
> http://cr.openjdk.java.net/~plevart/misc/ClassValue.Alternative2/webrev.02/ 
> 
> 
> Regards, Peter


-- 

 
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