RFR: 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures

[Kim Barrett]

> On May 26, 2016, at 8:32 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 27/05/2016 9:27 AM, Kim Barrett wrote:
>>>> This also seems like it might be generally useful.  Would it make
>>>> sense to add it to OrderAccess?
>>> 
>>> I tried and could not get it to work. As I said earlier in the thread it either failed to compile or else became self-referential and hit an infinite loop at runtime. Trying to deal with that seemed out-of-scope for what I was trying to achieve here. I was also worried about silently changing other uses of load_ptr_acquire.
>>> 
>>> That said, your formulation of it may work better than mine. So I will give it another try.
>> 
>> It might require renaming the existing load_ptr_acquire(void*), or an explicit conversion in the template.
>> I’ve always felt kind of squeamish about load_ptr_acquire(void*).  I think making it an implementation
>> detail (private, with a different name, e.g. load_ptr_acquire_impl) that this template (moved into
>> OrderAccess) uses would add convenience and safety.  Assuming doing so doesn’t break something
>> that is making assumptions about it.
>> 
>> That would require updating the existing definitions for the new name, and possibly updating at least
>> some callers (many callers probably now look like (Foo*)load_ptr_acquire(…), and the explicit cast
>> becomes redundant with this suggested change, so can be removed incrementally).  OTOH, there
>> aren’t all that many callers...
>> 
>> That’s obviously a substantial change, and clearly out of scope for this task.
> 
> So the bottom line there is, this is out of scope. Right? :) I really don't want to start touching other uses of this API.

Yes, out of scope.  Might be worth an RFE; I’ll let you decide about that.