RFR: 8186166: Generalize Atomic::cmpxchg with templates

Kim Barrett kim.barrett at oracle.com
Fri Aug 18 19:58:14 UTC 2017


> 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.

Fixing the include dependencies isn't some completely hand-wavy dream.
There's been work done in that direction, and more is intended.
globalDefinitions has become (or maybe always was) a dumping ground
for lots of random stuff.  Because of its place near the root of all
includes, that random stuff can't use other things as part of the
implementation.  I recently flipped the dependency order for debug.hpp
and globalDefinitions.hpp so we could finally use the assert macro and
friends in globalDefinitions.hpp.  The recently created align.hpp and
arena.hpp were additional steps along the way.  Maybe the
jmumble_casts will be treated in a similar fashion.  There are
presently 27 files out of about 2600 C++ source files in Hotspot that
use those functions, which hardly seems like a "global" need.

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.



More information about the hotspot-dev mailing list