JDK-8293117 : Add atomic bitset functions
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 20
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-08-30
  • Updated: 2024-10-18
  • Resolved: 2023-05-02
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 21
17.0.11Fixed 21 b21Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
We need an Atomic version of setting bits, e.g. and/or/xor, like the one in accessFlags for general purpose use.

From [~jrose]

Suggestions for API shape:
Mimic whatever the intel intrinsics do for and/or/xor/add.  Prefer their names.
But, stay within the boundaries of what the C++ atomic API does (omit op-and-fetch, keep only fetch-and-op).  Use their names if it makes sense.
Key requirement: Have the return value contain enough information to infer the previous state of the variable, for those who care.
Key requirement: Robustly support “set one bit” and “clear one bit”, probably by logior and logand of multi-bit masks.
Higher-level bit setter could be update_bits(T bits, bool new_state) -> T old_bits.  The higher-level setter could use the optimization of not issuing a CAS if the bit (or bits) is (are) in the desired new state already.
Comments
[~mdoerr] Probably because nobody has found the need for specialized versions yet. These operations aren't (yet) widely used or (I think) in super performance-critical places. So the generic implementations are sufficing.
18-10-2024

[~kbarrett] I wonder why nobody has managed to implement the specialized versions for the individual platforms. Maybe nobody knows the right syntax ;-) Could you provide an example, please?
17-10-2024

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/2049 Date: 2023-12-13 10:11:51 +0000
13-12-2023

[jdk17u-fix-request] Approval Request from Aleksey Shipilëv Another clean backport to synchronize (pun intended) Atomics support across JDK releases, in order to simplify future backports and thus simplify maintenance. New test passes.
13-12-2023

Changeset: 8a70664e Author: Kim Barrett <kbarrett@openjdk.org> Date: 2023-05-02 21:27:01 +0000 URL: https://git.openjdk.org/jdk/commit/8a70664e5248cd6b9d63951729e93bf73eff004c
02-05-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13711 Date: 2023-04-28 07:10:40 +0000
28-04-2023

We could add something like (per [~jrose] suggestion): template<typename D, typename T> inline bool Atomic::change_bits(D volatile* dest, T dest_mask, // mask of bits which may be changed (0=>none) int effect) { // 1=>set, 0=>clear, -1=>toggle for (;;) { u1 d0 = *dest; u1 d1 = d0 ^ (dest_mask & (effect < 0 ? (T)-1 : effect ? d0 : ~d0)); if (d0 == d1) return false; d1 = Atomic::cmpxchg(dest, d0, d1); if (d0 == d1) return true; } } or split it out into bit_set, bit_clear, bit_toggle. Code that could potentially use this is in: java_lang_String::test_and_set_flag ClassLoaderData::clear_claim ClassLoaderData::try_claim set_defined_by_cds_in_class_path BitMap::par_set_bit/BitMap::par_clear_bit/BitMap::par_put_range_within_word AccessFlags::atomic_set[clear]_bits
28-02-2023