RFR: 8186166: Generalize Atomic::cmpxchg with templates

[Andrew Haley]

On 18/08/17 20:58, Kim Barrett wrote:
>> On Aug 18, 2017, at 9:21 AM, Andrew Haley <aph at redhat.com> wrote:
>>
>> On 14/08/17 03:41, Kim Barrett wrote:
>>> * Conversions between integers and floating point values are
>>> supported.  It was suggested during the discussion of the RFR for
>>> JDK-8184334 that this was not needed, as there are no uses of
>>> atomic/ordered floating point values in Hotspot.  However, I'm told
>>> VarHandles may include atomic floating point values.
>>
>> I am very strongly opposed to checking unused code into HotSpot.  Apart
>> from the obvious obervation that it's impossible to test, it makes far
>> more sense to add it if it is ever needed.
> 
> Maybe you overlooked this, buried in this long thread?
> 
> ---
> I was about to agree to removal of floating point from here.  Then I
> remembered the jmumble_cast suite of functions in
> globalDefinitions.hpp.  Erik and I had discussed a unification, with
> the jmumble_cast functions built on IntegerTypes.  We can't presently
> do that, because of include dependencies, but that's probably fixable.
> We see this utility as having application beyond Atomic &etc template
> reimplementation.
> ---
> 
> So the float conversion support in PrimitiveConversions is presently
> unused.  There are some tests for it though (unlike the jmumble_cast
> functions).  And we intend to use it, just haven't gotten there yet.

Umm, okay.

> BTW, the conversion technique presently used by the jmumble_cast suite
> is explicitly called out by gcc documentation as still being undefined
> behavior, even with the involvement of unions.

Umm, what?  Can you explain this a little more?  I'd have to search
for what jumble_cast might be.  The union trick is well defined by
GCC.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671