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

[Christian Thalinger]

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

> 
> Thanks!
> 
> /Claes
> 
>> 
>>> On Jul 15, 2016, at 2:12 PM, Claes Redestad <claes.redestad at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Aleksey and I would like to contribute this patch which change the
>>> inlining policy to treat @CallerSensitive as it would
>>> @ForceSensitive.
>>> 
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8161379
>>> Webrev: http://cr.openjdk.java.net/~redestad/8161379/webrev.01/
>>> 
>>> The issue is that the JNI call behind Reflection.getCallerClass() is
>>> very expensive compared to the C2 intrinsic. This shows up in various
>>> microbenchmarks stress-testing reflection, method handle lookup etc,
>>> and can be linked to a number of intermittent regressions we see appear
>>> in various benchmarks.
>>> 
>>> See the bug for more information.
>>> 
>>> Testing: JPRT -testset hotspot, RBT hotspot-nightly-compiler
>>> 
>>> Thanks!
>>> 
>>> /Claes
>>