RFR: 8154750: Add missing OrderAccess operations to ClassLoaderData lock-free data structures
Kim Barrett
kim.barrett at oracle.com
Fri May 27 20:41:52 UTC 2016
> 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.
More information about the hotspot-runtime-dev
mailing list