@HotSpotIntrinsicCandidate and native prefixes (original) (raw)

Volker Simonis volker.simonis at gmail.com
Thu Mar 23 11:43:21 UTC 2017

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

More information about the hotspot-dev mailing list