RFR: 8349944: [JMH] sun.misc.UnsafeOps cannot access class jdk.internal.misc.Unsafe [v2]

[Nicole Xu]

On Fri, 21 Feb 2025 07:01:42 GMT, Nicole Xu <duke at 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