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

Christian Thalinger cthalinger at twitter.com
Mon Jul 18 23:59:24 UTC 2016

> On Jul 18, 2016, at 9:36 AM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 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.

It is, indeed.  The right way to do this is to add the @ForceInline annotation in the source code.

> Thanks,
> -Aleksey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160718/cf474dab/attachment.html>

More information about the hotspot-compiler-dev mailing list