On Fri, 21 Feb 2025 07:10:16 GMT, Alan Bateman <al...@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
