Removing ldar acquire from safepoint_poll method

[Samuel Chee]

Hello,

I was looking at whether it would be valid to remove the acquire from safepoint_poll completely from here which emits an ldar instead of a ldr for memory ordering. [1] As currently, there is only a single instance of this argument being used, in the panama downstream ffi. [2]
And similar changes have been made to remove the acquire argument from other native methods [3] with the reasoning being that threads now disarm their own poll value and hence an ldar is no longer needed. Hence the same reasoning should apply when removing the acquire from the safepoint_poll used in the panama ffi and all other uses of safepoint_poll (especially since panama ffi is the only one which uses acquire). If it applies, this means the acquire argument functionality should be able to be removed completely from the safepoint_poll method.

This change seemed to have been allowed when concurrent thread-stack processing and watermarking was introduced and the SafepointMechanism::update_poll_values method was updated such that the poll value could not be armed when leaving this method. [4] [5] As previously this may have not been the case as it could exit this function with an armed poll value. [6]
Given the complexity of the code - particularly around safepoints and thread-handshake mechanisms, which have evolved significantly over time - I’d like to clarify a few aspects to ensure this change is correct.
My questions are:

1. What specifically allowed this change to be made to the other JNIs? Why is the ldar acquire no longer needed?
2. Is there a reason why this was not done to the panama FFI safepoint_poll when the acquire arguments were removed from the other JNIs in [3]?
3. Why is a load_acquire required here [7] for before the handshake operation or global state but not from some of the existing jit-emitted code?
4. Why did the introduction of watermarking introduce both a poll word and poll page? Why is both needed?
5. And any more additional context on how safepointing and poll values work.

Any clarification on the matter would be much appreciated!
Samuel Chee


[1] https://github.com/openjdk/jdk/blob/4c695fa8a459adcdb8cdfe9e90783007c65fb90e/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L556
[2] https://github.com/openjdk/jdk/blob/482538b100856afe2252395d47e576e6c6d885ce/src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp#L292
[3] https://bugs.openjdk.org/browse/JDK-8337657
[4] https://github.com/openjdk/jdk/pull/296/files#diff-2a18ec5d55c3c0c18669d55ff48fb455b633d152132915caf65766e41a5a58ab
[5] https://openjdk.org/jeps/376
[6] https://github.com/openjdk/jdk/blob/a2f651904d1a1fdb14428be5485709b8ff252331/src/hotspot/share/runtime/safepointMechanism.cpp#L86,
[7] https://github.com/openjdk/jdk/blob/765cef45465806e53f11fa7d92b9c184899b0932/src/hotspot/share/runtime/safepointMechanism.inline.hpp#L48

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/attachments/20250501/5d3f6859/attachment-0001.htm>