RFR: 8161379: Force inline methods calling Reflection.getCallerClass

Claes Redestad claes.redestad at oracle.com
Fri Aug 5 20:22:36 UTC 2016


On 08/05/2016 12:56 PM, Aleksey Shipilev wrote:
> This looks good to me, Claes.

Thanks!

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

While source control history helps, I think it's alright with some
additional verbiage here in case someone figures out a way to
implement any of these without Reflection.getCallerClass (since
we ideally don't want to @ForceInline in too many places)

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



More information about the core-libs-dev mailing list