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

[David Holmes]

On 9/06/2021 11:54 pm, Stefan Karlsson wrote:
> On Wed, 9 Jun 2021 13:36:31 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    read once
>>
>> src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 478:
>>
>>> 476: }
>>> 477:
>>> 478: const HeapWord* ThreadLocalAllocBuffer::start_relaxed() const {
>>
>> Why do we need the "relaxed" terminology? By default accessors have no memory ordering properties.
> 
> 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. I also see nothing in atomic.hpp that states 
that Atomic::load/store implement memory_order_relaxed ?? 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?

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4363
>