RFR: 8186166: Generalize Atomic::cmpxchg with templates
aph at redhat.com
Sat Aug 19 07:57:43 UTC 2017
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
> 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.
> 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
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-dev