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

[Stefan Karlsson]

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 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.

> 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