On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <d...@openjdk.org> wrote:
>> The UnsafeOps JMH benchmark fails with the following error: >> >> ``` >> java.lang.IllegalAccessError: class >> org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot >> access class jdk.internal.misc.Unsafe (in module java.base) because module >> java.base does not export jdk.internal.misc to unnamed module @0x520a3426 >> ``` >> >> Since this micro-benchmark is created for `sun.misc.Unsafe` rather than >> `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. >> >> Note that even it will raise "proprietary API" warnings after this >> patch, it is acceptable because the relevant APIs are bound for removal >> for the integrity of the platform. > > Nicole Xu has updated the pull request incrementally with two additional > commits since the last revision: > > - 8349944: [JMH] sun.misc.UnsafeOps cannot access class > jdk.internal.misc.Unsafe > > The UnsafeOps JMH benchmark fails with the following error: > > ``` > java.lang.IllegalAccessError: class > org.openjdk.bench.sun.misc.UnsafeOps (in unnamed module @0x520a3426) cannot > access class jdk.internal.misc.Unsafe (in module java.base) because module > java.base does not export jdk.internal.misc to unnamed module @0x520a3426 > ``` > > Since this micro-benchmark is created for `sun.misc.Unsafe` rather than > `jdk.internal.misc.Unsafe`, we change it back as before JDK-8332744. > > Note that even it will raise "proprietary API" warnings after this > patch, it is acceptable because the relevant APIs are bound for removal > for the integrity of the platform. > > Change-Id: Ia7c57c2ca09af4b2b3c6cc10ef4ae5a9f3c38a4c > - Revert "8349944: [JMH] sun.misc.UnsafeOps cannot access class > jdk.internal.misc.Unsafe" > > This reverts commit ebc32ae2c6e448075fedbdbb2b4879c43829c44b. > Would it be possible to configure the build of the microbenchmarks to not > pass `-Werror`, so they don't break when sunapi diagnostics are emitted? > > > Note that even it will raise "proprietary API" warnings after this patch, > > it is acceptable because the relevant APIs are bound for removal for the > > integrity of the platform. > > It will not raise those diagnostics today, because they don't work for this > compilation due to > [JDK-8349846](https://bugs.openjdk.org/browse/JDK-8349846). If that issue is > fixed again it would break the build of these benchmarks, e.g. with > [1ab1c1d](https://github.com/openjdk/jdk/commit/1ab1c1d53b86228be85aac96fa5d69db39ac6317) > backed out and with this change it would fail with: > > ``` > test/micro/org/openjdk/bench/sun/misc/UnsafeOps.java:27: warning: Unsafe is > internal proprietary API and may be removed in a future release > import sun.misc.Unsafe; > ^ > ... > error: warnings found and -Werror specified > ``` Thank you for your comments. I understand your concerns about potential "proprietary API" warnings if we revert to using `sun.misc.Unsafe`. However, this specific microbenchmark is designed for `sun.misc.Unsafe`, not `jdk.internal.misc.Unsafe`. For the "proprietary API" warning, while not passing `-Werror` during the build process for the microbenchmarks could have broad implications, I wonder if we could take a more targeted approach. Would it be possible to exclude just this particular microbenchmark from sunapi diagnostics? @AlanBateman @liach Do you have any comments on that? I'd appreciate your inputs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2686755067
