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

[Chen Liang]

On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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.
>
> Thanks for restoring, this micro was specifically for sun.misc.Unsafe. I'm not wondering about the FFM micros that were also changed by JDK-8332744. Might not matter there but I think the original motive was to compare against sun.misc.Unsafe usage.

@AlanBateman Can you review this if this patch looks good in principle? Or should this bench be nuked like the virtual thread continuation one?

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

PR Comment: https://git.openjdk.org/jdk/pull/23686#issuecomment-2759689700