RFR: 8186166: Generalize Atomic::cmpxchg with templates
rkennke at redhat.com
Tue Aug 15 14:22:58 UTC 2017
Am 14.08.2017 um 11:56 schrieb Kim Barrett:
>> 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
> type int*.
> 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.
I don't see that anywhere. The only situations that I could find are a
few places where dest is cast to (volatile foo*), which makes me
question whether that dest field should be marked volatile in the first
place. I see no patterns as you described above involving any const
casts. And I am absolutely against introducing some machinery that is
not actually used. If it's not used, it's dead, and only increases debt
rather than decrease it. (Note: the situation would be different if it
were a public API. but it isn't)
More information about the hotspot-dev