RFR: 8333756: java/lang/instrument/NativeMethodPrefixApp.java failed due to missing intrinsic [v2]

[Jaikiran Pai]

> Can I please get a review of this test-only change which fixes an issue that was introduced due to the refactoring that we did in https://bugs.openjdk.org/browse/JDK-8333130? This PR addresses the failure reported in https://bugs.openjdk.org/browse/JDK-8333756.
> 
> The `NativeMethodPrefixApp` test uses a `javaagent` `NativeMethodPrefixAgent` which modifies the name of the native methods using the `java.lang.instrument.Instrumentation` instance:
> 
> public static void premain (String agentArgs, Instrumentation instArg) {
>     inst = instArg;
>     System.out.println("Premain");
> 
> ...
>     instArg.setNativeMethodPrefix(t0, "wrapped_tr0_");
>     instArg.setNativeMethodPrefix(t1, "wrapped_tr1_");
>     instArg.setNativeMethodPrefix(t2, "wrapped_tr2_");
> 
> 
>  The Hotspot VM allows for methods on a class to be annotated with an (VM internal) `jdk.internal.vm.annotation.IntrinsicCandidate` annotation. When a class that contains any methods that are annotated with `@IntrinsicCandidate` is loaded, the VM checks that the corresponding method(s) have an intrinsic available. It uses the method name to check for the presence of the intrinsic. In the absence of an intrinsic for a `@IntrinsicCandidate` method, the VM throws an error and exits. This behaviour is controlled by the `-XX:+/-CheckIntrinsics` option. By default that option is enabled, implying that an error will be thrown if the intrinsic isn't found.
> 
> In the case where/when this test fails, it so happens that the JVM loads a class which has a `@IntrinsicCandidate` on a `native` Java method. For example, on the failing host, I could see this class loading sequence:
> 
> 
> tr2: Loading java/util/Date
> tr1: Loading java/util/Date
> tr0: Loading java/util/Date
> tr2: Loading sun/util/calendar/CalendarSystem
> tr1: Loading sun/util/calendar/CalendarSystem
> tr0: Loading sun/util/calendar/CalendarSystem
> tr2: Loading sun/util/calendar/CalendarSystem$GregorianHolder
> tr1: Loading sun/util/calendar/CalendarSystem$GregorianHolder
> tr0: Loading sun/util/calendar/CalendarSystem$GregorianHolder
> ...
> tr2: Loading sun/util/calendar/ZoneInfoFile$Checksum
> tr1: Loading sun/util/calendar/ZoneInfoFile$Checksum
> tr0: Loading sun/util/calendar/ZoneInfoFile$Checksum
> tr2: Loading java/util/zip/Checksum
> tr1: Loading java/util/zip/Checksum
> tr0: Loading java/util/zip/Checksum
> tr2: Loading java/util/zip/CRC32
> tr1: Loading java/util/zip/CRC32
> tr0: Loading java/util/zip/CRC32
> Method [java.util.zip.CRC32.wrapped_tr2_update(II)I] is annotated with @IntrinsicCandidate, but no...

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  update code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19595/files
  - new: https://git.openjdk.org/jdk/pull/19595/files/95a939a1..17eb4421

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19595&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19595&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19595.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19595/head:pull/19595

PR: https://git.openjdk.org/jdk/pull/19595