@HotSpotIntrinsicCandidate and native prefixes

[Volker Simonis]

On Thu, Mar 23, 2017 at 10:30 AM, Michael Rasmussen
<michael.rasmussen at zeroturnaround.com> wrote:
> On Mar 14, 2017 23:03, "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> wrote:
>
> Yes, you are right. Then the only option is:
>   -XX:+UnlockDiagnosticVMOptions -XX:-CheckIntrinsics
>
> Best regards,
> Vladimir Ivanov
>
>
> Thinking about this a bit further, are these messages going to be enabled
> by default when jdk9 is released?
>
> These kind of messages are clearly only for the benefit of hotspot
> developers, and has zero value to end users, who wouldn't know anything
> about this annotation or the implications of it.
>
> For the average user, heck you have to be a pretty advanced user to even
> know what intrinsic means, getting warnings like this, I can only think it
> would do a lot more harm than good, thinking that their installation is
> broken or something.
>

I think this issue is somehow a counterpart of and related to
"JDK-8013579: Intrinsics for Java methods don't take class
redefinition into account" :)

So if you transform a non-native method which is subject to
intrinsification you should be aware that your transformations will be
lost, once the method will be intrinsified!

That said, I agree that the warning message is hard to understand for
the average Java developer but I think it has a value. As Vladimir
pointed out, if you wrap a native method, which would be intrinisfied
otherwise, through class transformation / SetNativeMethodPrefix, that
method will not be intrinsified any more. So if you do the
transformation for profiling for example, you'd profile a different
thing.

I actually somehow missed "8131326: Enable CheckIntrinsics in all
types of builds" which enabled CheckIntrinsics in product builds by
default (before it was only enabled in debug builds). Not sure what
was the rational behind this change (CC'ed Zoltan who did the change)
but I'm pretty sure that the effects of SetNativeMethodPrefix haven't
been taken into account when that change was made. In the end it paid
off, otherwise you wouldn't have found this issue :)

Regards,
Volker

> /Michael