RFR (M): 8184334: Generalizing Atomic with templates

[Andrew Haley]

On 14/07/17 17:28, Erik Österlund wrote:
> 
> As for oracle-external ports, I would appreciate if port maintainers
> could check if it seems to make sense. I have done my best to try to
> make the appropriate changes where needed.

It seems to, but it looks over-engineered.  We're relying on the C++
compiler to get rid of all of the casts and calls, but it's always
better not to write code we don't want to execute.  So, could you add
a little commentary explaining what all this SignedType stuff does?  I
guess it must be necessary or you wouldn't have written it, but I
don't know why.

Monitor::TryFast
->  Atomic::cmpxchg_ptr
  ->  Atomic::cmpxchg<long, long, long>
    ->  Atomic::specialized_cmpxchg<long>
      ->  generic_cmpxchg<long>
        ->  __sync_val_compare_and_swap

I wonder if it's intended to avoid undefine behaviour by always
guaranteeing that we store a signed type, but on the other hand
cmpxchg_ptr doesn't much seem to worry about handing a void** as an
intptr_t*, so it can't be that, and besides we compile with
-fno-strict-aliasing (or it equivalent on other machines).

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