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