RFR (M): 8184334: Generalizing Atomic with templates

[David Holmes]

Hi Kim,

Good planning on Erik's part to go on vacation just as I have returned ;-)

On 1/08/2017 4:18 AM, Kim Barrett wrote:
>> On Jul 28, 2017, at 12:25 PM, Erik Osterlund <erik.osterlund at oracle.com> wrote:
>>
>> Hi Andrew,
>>
>> In that case, feel free to propose a revised solution while I am gone.
> 
> Erik has asked me to try to make progress on this while he's on
> vacation, rather than possibly letting it sit until he gets back.

Okay, while Erik is gone perhaps you can clarify a few things. As Andrew 
and Roman have expressed, I too find this:

+   template <typename T, typename U, typename V>
+   inline static U cmpxchg(T exchange_value, volatile U* dest, V 
compare_value, cmpxchg_memory_order order);

totally unintuitive and unappealing. I do not understand the rationale 
for this this at all. It does not make any sense to me to allow T, U and 
V to be different types (even if constrained). It has been stated that 
if we force them to all be the same there is some problem with literals 
and the need for casts, but I don't understand what that problem would be.

I'm also unclear about these assertions:

   STATIC_ASSERT(sizeof(T) <= size_t(BytesPerWord)); // Does the machine 
support atomic wide accesses?

as that is not a guarantee of atomic access support. It isn't always 
even a necessary condition; but it certainly isn't sufficient.

The conversion from use of the j* types also seems an unnecessary 
disruption to the APIs. Bear in mind in many cases these functions are 
for operating on Java-level fields and so have Java types. Those java 
types are well defined (jint is signed 32-bit, jshort is signed 16-bit 
etc etc). If compilers had had broad support for the int8_t, int16_t, 
int32_t etc typedefs back in Java 5 then perhaps we would have used 
those instead of the j* aliases/synonyms. But changing it now seems 
disruptive and driven by personal preference IMHO.

I don't understand methods like this:

   75   template <typename T>
   76   inline static T specialized_xchg(T exchange_value, volatile T* 
dest) {
   77     STATIC_ASSERT(Never<T>::value);
   78     return exchange_value;
   79   }
   80

is this a new form of ShouldNotReachHere() ?? ie these functions should 
always be overridden by each platform?

I admit I'm not very fluent in template-ese. For example how does one 
read this, and what does it mean ??

typedef Conditional<IsDerived<PlatformAtomic, AllStatic>::value, 
PlatformAtomic, GeneralizedAtomic>::type AtomicImpl;

And I'm still trying to get my head around the introduced "trait" stuff. 
(I hate pseudo-languages that can be written within other languages :( ).

Thanks,
David
-----

> (This is just one of a large stack of patches Erik has prepared toward
> the GC access interface that he's been talking about for a while.
> Providing a solid base for that work is the underlying goal for
> changing atomics.)  I'm getting caught up on the discussion, and
> looking at Erik's most recent proposal.  I should have something more
> concrete soon, possibly just agreeing with Erik's recent ideas,
> possibly some alternative.  I'm also open to suggestions…
> 
>