RFR(S): 8161379: @CallerSensitive methods should be forcefully inlined to get Reflection.getCallerClass optimization

[Aleksey Shipilev]

On 07/18/2016 08:32 PM, Christian Thalinger wrote:
>> On Jul 16, 2016, at 12:22 AM, Claes Redestad
>> <claes.redestad at oracle.com> wrote:
>> 
>> On 2016-07-16 04:17, Christian Thalinger wrote:
>>> Why are you not setting the _force_inline bit on
>>> @CallerSensitive?  It would be less intrusive and more global so
>>> other compilers would pick it up as well.
>> 
>> We figured having ability to distinguish between reasons for why
>> we're force inlining could come in handy, but since the behavior
>> would be the same I'd be happy to simplify this if that'll make
>> things easier for other compilers.
> 
> It would.  Just document somewhere (in HotSpot) that @CallerSensitive
> also enables @ForceInline.

My first patch did this. But then I realized we may want to be able to
selectively weaken @CS inlining exceptions, rather that get everything
@FI is excepted from: "inlining too deep", "size > DesiredMethodLimit",
"NodeCountInliningCutoff"

I have no strong opinion whether we should say @CS implies @FI or not.
It seems odd (dirty?) to hijack force_inline bit for something that is
not explicitly @FI though.

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160718/df9141a9/signature.asc>