[GR-49852] [GR-49613] Update JVMCI to 22+22-jvmci-b01.

[graalvmbot]

Update to 22+22-jvmci-b01

• Adopt "JDK-8239508 JFR: @RemoveFields".
  • Already reported on Github: Update JFR mirror event registration to account for new JDK class  #7739
• Adopt "JDK-8288899 java/util/concurrent/ExecutorService/CloseTest.java failed with "InterruptedException: sleep interrupted""
  • PR with an innocent title that changes the signature of the public non-final ForkJoinPool#invokeAll method and thus is making JDK 22 source incompatible with previous JDKs. This is not only a problem for native-image but for all Java code that subclass ForkJoinPool.
  • CSR (Compatibility & Specification Review) for this change: JDK-8309407

[roberttoyonaga]

For JDK 22, I think you will still need to call createMirrorEventsMapping(). But createMirrorEventsMapping() will need ReflectionUtil.lookupClass(false, "jdk.jfr.internal.MirrorEvents"); instead of ReflectionUtil.lookupClass(false, "jdk.jfr.internal.instrument.JDKEvents"); depending on what JavaVersionUtil.JAVA_SPEC returns.

Additionally, I think an @Alias will be required for jdk.jfr.internal.instrument.JDKEvents#mirrorEventClasses similar to what already exists in Target_jdk_jfr_internal_instrument_JDKEvents for JDK 21.

[zapster]

Thanks so much for the suggestions @roberttoyonaga! Interestingly, the mirrored events are not covered by our testing.

Since the JDK update is rather critical, we plan to merge this PR as is and deal with the remaining JFR changes in a follow-up PR. We should also add some testing so that we cover these cases in our gate jobs.

If you could prepare a PR, we would very much appreciate it as it would speed up things. I can let you know as soon as the labjdk builds are publicly available, so you can start on top of this PR without waiting for it to merge.

Otherwise, if you don't have time, I can prepare a PR as well.

[zapster]

The labsJDK 22+22 artifacts are available: https://github.com/graalvm/labs-openjdk/releases

[roberttoyonaga]

If you could prepare a PR, we would very much appreciate it as it would speed up things.

Hi @zapster! Yes, I'll prepare a PR for these JFR updates

[roberttoyonaga]

Hi @zapster, on second thought, we may not actually need to do much further to accommodate the changes related to MirrorEvents.java. The new behaviour is that jdk.jfr.internal.MirrorEvents maintains a cache of all the mirror event classes, instead of that cache needing to be built in JDKEvents. This means the extra step of using SecuritySupport#registerMirror is unnecessary in JDK22. So now we also don't have to do this extra step at native image build-time before manually retransforming the JFR event classes in JfrEventSubstitution anymore.

I made a PR that adds a test to verify mirror events are handled correctly and also adds a substitution to reset MirrorEvent#mirrorEventClasses. #7771

[zapster]

Awesome, thanks a lot!