Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

[Claes Redestad]

Thanks! 

Up to 12-15x on some reflection micros, but it varies wildly. This change does 
not improve the best case performance, but rather eliminates a cause for 
degradation and high run to run variance.

/Claes

Mandy Chung  skrev: (5 augusti 2016 14:55:59 GMT-07:00)
>
>> On Aug 5, 2016, at 1:22 PM, Claes Redestad
> wrote:
>> 
>> http://cr.openjdk.java.net/~redestad/8161379/jdk.02/
>> 
>
>Looks fine.
>
>How much improvement do you see from the benchmark run with this patch?
>
>Mandy

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

[Mandy Chung]

> On Aug 5, 2016, at 1:22 PM, Claes Redestad  wrote:
> 
> http://cr.openjdk.java.net/~redestad/8161379/jdk.02/
> 

Looks fine.

How much improvement do you see from the benchmark run with this patch?

Mandy

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

[Aleksey Shipilev]

On 08/05/2016 11:22 PM, Claes Redestad wrote:
> On 08/05/2016 12:56 PM, Aleksey Shipilev wrote:
>> I wouldn't mind to have a comment at @ForceInline line mentioning this
>> is for Reflection.getCallerClass() optimization. But, it might be
>> recoverable from the source control anyway.
> 
> Sure, how about:
> 
> @ForceInline // to ensure Reflection.getCallerClass optimization
> 
> http://cr.openjdk.java.net/~redestad/8161379/jdk.02/

+1

-Aleksey

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

[Aleksey Shipilev]

This looks good to me, Claes.

I wouldn't mind to have a comment at @ForceInline line mentioning this
is for Reflection.getCallerClass() optimization. But, it might be
recoverable from the source control anyway.

Thanks,
-Aleksey

On 08/05/2016 10:37 PM, Claes Redestad wrote:
> Anyone?
> 
> On 07/19/2016 08:16 AM, Claes Redestad wrote:
>> Hi,
>>
>> most @CallerSensitive methodscall Reflection.getCallerClass(), which
>> turn out to have problematic performance characteristics when it fails
>> to inline.
>>
>> Making @CallerSensitive imply @ForceInline actually works rather well
>> across benchmarks, but didn't meet with approval from hotspot-compiler
>> because it's a hack (unlike @ForceInline /s).
>>
>> Instead, here is a patch to explicitly @ForceInline those methods where
>> it can plausibly be helping with performance:
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161379
>>
>> Thanks!
>>
>> /Claes
>>
> 

Re: RFR: 8161379: Force inline methods calling Reflection.getCallerClass

[Claes Redestad]

Anyone?

On 07/19/2016 08:16 AM, Claes Redestad wrote:

Hi,

most @CallerSensitive methodscall Reflection.getCallerClass(), which
turn out to have problematic performance characteristics when it fails
to inline.

Making @CallerSensitive imply @ForceInline actually works rather well
across benchmarks, but didn't meet with approval from hotspot-compiler
because it's a hack (unlike @ForceInline /s).

Instead, here is a patch to explicitly @ForceInline those methods where
it can plausibly be helping with performance:

Webrev: http://cr.openjdk.java.net/~redestad/8161379/jdk.01/
Bug: https://bugs.openjdk.java.net/browse/JDK-8161379

Thanks!

/Claes