Hotspot VM currently has a "-XX:+PrintIntrinsics" option which prints out the intrinsic that was used during a java program execution. For example,
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics Foo
will print:
@ 13 java.lang.Integer::reverseBytes (28 bytes) (intrinsic)
if/when the intrinsic for Integer.reverseBytes(int) method gets used.
Similary there are other VM options, "-XX:ControlIntrinsic" and "-XX:DisableIntrinsic" which take a intrinsic id as the option value. Intrinsic ids may not always be of the form "_<methodName>". In fact, the intrinsic id for the intrinsic corresponding to "java.lang.Integer.reverseBytes(int)" method is "_reverseBytes_i". So if one has to disable this intrinsic, they will have to know this intrinsic id. Right now, the only way to determine an intrinsic id for a method is by looking at the code in src/hotspot/share/classfile/vmIntrinsics.hpp which maintains this mapping.
To help situations like these where intrinsic ids aren't easily known, it would be better to introduce a VM option which lists the intrinsics that are supported by the current runtime. Including both the Java <class>.<method> name and the corresponding intrinsic id for that method in the output for each intrinsic would be useful. Something like:
java -XX:+UnlockDiagnosticVMOptions -XX:ListIntrinsics
...
java.lang.Integer::reverseBytes (_reverseBytes_i)
...
java -XX:+UnlockDiagnosticVMOptions -XX:+PrintIntrinsics Foo
will print:
@ 13 java.lang.Integer::reverseBytes (28 bytes) (intrinsic)
if/when the intrinsic for Integer.reverseBytes(int) method gets used.
Similary there are other VM options, "-XX:ControlIntrinsic" and "-XX:DisableIntrinsic" which take a intrinsic id as the option value. Intrinsic ids may not always be of the form "_<methodName>". In fact, the intrinsic id for the intrinsic corresponding to "java.lang.Integer.reverseBytes(int)" method is "_reverseBytes_i". So if one has to disable this intrinsic, they will have to know this intrinsic id. Right now, the only way to determine an intrinsic id for a method is by looking at the code in src/hotspot/share/classfile/vmIntrinsics.hpp which maintains this mapping.
To help situations like these where intrinsic ids aren't easily known, it would be better to introduce a VM option which lists the intrinsics that are supported by the current runtime. Including both the Java <class>.<method> name and the corresponding intrinsic id for that method in the output for each intrinsic would be useful. Something like:
java -XX:+UnlockDiagnosticVMOptions -XX:ListIntrinsics
...
java.lang.Integer::reverseBytes (_reverseBytes_i)
...