Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-29 Thread Vladimir Ivanov
Thanks, John. Best regards, Vladimir Ivanov On 10/29/14, 12:21 AM, John Rose wrote: Good, I'm happy. Reviewed. — John On Oct 28, 2014, at 12:04 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com mailto:vladimir.x.iva...@oracle.com wrote: John, thanks for the feedback! See my answers inline.

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-28 Thread Vladimir Ivanov
John, thanks for the feedback! See my answers inline. Updated version: http://cr.openjdk.java.net/~vlivanov/8059877/webrev.02/ The algorithm looks fine, as long as the count is small. (Otherwise we might want to spend effort recompiling the DontInline LF. Yes, the intention is to have it

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-28 Thread John Rose
Good, I'm happy. Reviewed. — John On Oct 28, 2014, at 12:04 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: John, thanks for the feedback! See my answers inline. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-15 Thread Paul Sandoz
On Oct 14, 2014, at 8:54 PM, Vladimir Ivanov vladimir.x.iva...@oracle.com wrote: Paul, Thanks for the feedback! Updated version: http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/ http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-15 Thread Vladimir Ivanov
Thanks, Paul! Updated version: http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/ ... This is a good example to add to our stomping on a final field discussion, i think here it is definitely a very special case with a careful dance between updating and inlining (updateForm is also

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-14 Thread Vladimir Ivanov
Paul, Thanks for the feedback! Updated version: http://cr.openjdk.java.net/~vlivanov/8059877/webrev.01/ http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059877 Generally looks ok. - MethodHandleImpl 786 if

[9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-10 Thread Vladimir Ivanov
http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8059877 LambdaForm sharing introduces profile pollution in compiled LambdaForms. The most serious consequence is inlining distortion, which severely degrade peak performance. The main victim is

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-10 Thread Remi Forax
Hi Vladimir, Why do you need getHistoricInt ? Is it because Unsafe.getInt() doesn't do any constant folding ? BTW, why getHistoricInt is named getHistoricInt ? cheers, Rémi On 10/10/2014 09:08 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~vlivanov/8059877/webrev.00/

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-10 Thread Vladimir Ivanov
Remi, Why do you need getHistoricInt ? Is it because Unsafe.getInt() doesn't do any constant folding ? Exactly. I need a compile-time constant to feed it to the compiler to guide compilation. BTW, why getHistoricInt is named getHistoricInt ? From application perspective, the call returns

Re: [9] [8u40] RFR (M): 8059877: GWT branch frequencies pollution due to LF sharing

2014-10-10 Thread Remi Forax
On 10/10/2014 10:42 PM, Vladimir Ivanov wrote: Remi, Why do you need getHistoricInt ? Is it because Unsafe.getInt() doesn't do any constant folding ? Exactly. I need a compile-time constant to feed it to the compiler to guide compilation. BTW, why getHistoricInt is named getHistoricInt ?