RFR: 8267579: Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow

[David Holmes]

On 10/06/2021 4:55 pm, Stefan Karlsson wrote:
> On Thu, 10 Jun 2021 04:35:50 GMT, David Holmes <david.holmes at oracle.com> wrote:
> 
>>> I'm not sure what you are asking, but Atomic::load implements the "relaxed" semantics equivalent to using MO_RELAXED in the Access API.
>>
>> I see this terminology is used in some of the GC code but I was not
>> aware of its existence.
> 
> This is not a GC-specific terminology, but a C++11 terminology:
> https://en.cppreference.com/w/cpp/atomic/memory_order

I meant in the context of the hotspot sources and its use in method names.

>> I also see nothing in atomic.hpp that states
>> that Atomic::load/store implement memory_order_relaxed ??
> 
> In atomic.hpp there are references to relaxed at the top of the file:
> 
> enum atomic_memory_order {
>    // The modes that align with C++11 are intended to
>    // follow the same semantics.
>    memory_order_relaxed = 0,
>    memory_order_acquire = 2,
>    memory_order_release = 3,
>    memory_order_acq_rel = 4,
>    // Strong two-way memory barrier.
>    memory_order_conservative = 8
> };
> 
> 
> But you are right, nothing here helps the reader understand that Atomic::load implies relaxed. This needs to be better documented.

What am I missing - I can't see any memory barrier related instructions 
  associated with basic Atomic::load and store. Granted store needs 
nothing on TSO and on non-TSO the barrier may be implicit in whatever 
platform intrinsic is used; but loads would also need explicit barriers 
to prevent reordering ??

David
-----

>> Is the
>> difference between unordered and relaxed what you get from applying
>> volatile to the variable being accessed? So unordered from a h/w
>> perspective but with some constraints on the compiler to maintain
>> program order?
> 
> I talked to @fisk about this yesterday, and IIUC relaxed access are not supposed to be reordered by the HW, but volatile access could be.
> 
>>
>> Thanks,
>> David
>> -----
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4363
>