RFR (M): 8184334: Generalizing Atomic with templates
david.holmes at oracle.com
Wed Aug 2 03:35:46 UTC 2017
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*
78 return exchange_value;
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 :( ).
> (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…
More information about the hotspot-dev