RFR: 8186166: Generalize Atomic::cmpxchg with templates
kim.barrett at oracle.com
Mon Aug 14 15:56:42 UTC 2017
> On Aug 14, 2017, at 10:28 AM, Roman Kennke <rkennke at redhat.com> wrote:
> I still don't understand why we want to allow for different types for
> the new and expected values and the memory location (T, D and U). We
> haven't allowed for this before, why are we doing it now?
Different types are only permitted in the pointer value case,
e.g. cmpxchg(T*, D* volatile*, U*).
The compare_value type is permitted to differ from the destination's
value type only in cv-qualifiers. Consider a member variable "var" of
const int* old_value = var;
... compute new_value ...
cmpxchg(new_value, &var, old_value);
It is perfectly reasonable and appropriate to const-qualify
old_value's type in that way. But that would require a source level
cast if cmpxchg required an exact type match for *dest and
We permit the exchange_value type to be less cv-qualified than the
*dest type. We also permit derived to base conversions. Both of
those are natural and type-safe, and may eliminate the need for some
source level casts.
> We haven't allowed for this before, why are we doing it now?
Because of the complete type-discarding done by cmpxchg_ptr, I suggest
we have no clue what our current code might or might not be doing.
More information about the hotspot-dev