Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe #20632

Closed
tajila opened this issue Nov 19, 2024 · 14 comments
Closed

JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe #20632

tajila opened this issue Nov 19, 2024 · 14 comments
Assignees

Comments

@tajila
Copy link
Contributor

tajila commented Nov 19, 2024

See https://openjdk.org/jeps/498

@tajila tajila added this to the Java 24 (0.50) milestone Nov 19, 2024
Copy link

Issue Number: 20632
Status: Open
Recommended Components: comp:vm, comp:gc, comp:jclextensions

@tajila tajila assigned theresa-m and unassigned hangshao0 Nov 19, 2024
@tajila
Copy link
Contributor Author

tajila commented Nov 19, 2024

I expect it to land by next week.

@theresa-m
Copy link
Contributor

I don't think there is any vm work to do here. I will run the OpenJ9 functional tests with --sun-misc-unsafe-memory-access=warn to see if any tests will fail once it becomes the default setting.

@theresa-m
Copy link
Contributor

There were no test failures with --sun-misc-unsafe-memory-access=warn on. I think this issue can be closed.

Copy link

Issue Number: 20632
Status: Closed
Actual Components: comp:vm, JEP
Actual Assignees: No one :(
PR Assignees: No one :(

@pshipton
Copy link
Member

I would be good to run openjdk testing as well.

What happens if we run with --sun-misc-unsafe-memory-access=deny? If there is usage from OpenJ9 class library code that is going to generate warnings, I think it needs to be removed so user's don't get these warnings.

@pshipton pshipton reopened this Nov 20, 2024
@theresa-m
Copy link
Contributor

I'll try with openjdk tests and --sun-misc-unsafe-memory-access=deny as well.

OpenJ9 does not generate any warning for this, it is done in https://github.com/openjdk/jdk/blob/master/src/jdk.unsupported/share/classes/sun/misc/Unsafe.java#L1860

@pshipton
Copy link
Member

The point is that OpenJ9 implements JCL code that uses Unsafe. If this code ends up generating a warning when run in a user application, this needs to be fixed.

@hzongaro
Copy link
Member

The point is that OpenJ9 implements JCL code that uses Unsafe. If this code ends up generating a warning when run in a user application, this needs to be fixed.

Does the OpenJ9 JCL code after version 8 use sun.misc.Unsafe or only jdk.internal.misc.Unsafe? Will warnings be reported for uses of either or only the former?

@pshipton
Copy link
Member

I think in theory it's all fine since OpenJ9 should (can) only use jdk.internal.misc.Unsafe.

@theresa-m
Copy link
Contributor

theresa-m commented Nov 21, 2024

I tried sanity and extended tests with --sun-misc-unsafe-memory-access=deny
https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder_Simple/39/
https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder_Simple/40/

The 3 test failures are all due to direct uses of the sun.misc.Unsafe library.

  • Test_UnsafeFence.testIntFence
  • Test_UnsafeFence.testLongFence
  • Cmvc199515.testCmvc199515

I'll try OpenJDK tests next.

@theresa-m
Copy link
Contributor

OpenJdk sanity tests has a failure in sun/misc/UnsafeMemoryAccessWarnings.java.UnsafeMemoryAccessWarnings which is being updated in OpenJDK.
https://hyc-runtimes-jenkins.swg-devops.com/view/Test_grinder/job/Grinder/45102/

@pshipton is there anything else to try before resolving this issue?

@pshipton
Copy link
Member

I can't think of anything else. Thanks for double checking.

Copy link

Issue Number: 20632
Status: Closed
Actual Components: comp:vm, JEP
Actual Assignees: No one :(
PR Assignees: No one :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants