TLAB pointer movement in Hotspot implementation

[Thomas Schatzl]

Hi,

On Thu, 2017-08-03 at 23:18 -0700, Krystal Mok wrote:
> Hi CJ,
> 
> The JavaThread::_allocated_bytes field is updated every time the
> thread's TLAB is being retired
> (ThreadLocalAllocBuffer::make_parsable()), and also
> when there's a big allocation that goes through the slow path
> (CollectedHeap::common_mem_allocate_noinit()). So, that keeps track
> of the cumulative sum of all GC heap memory allocated from this 
> thread.

This behavior is exactly what the somewhat generic description also
tries to cover: with -XX:UseTLAB (which is by default enabled), you get
allocation information on a TLAB basis, not an object basis.

> By adding that with the current TLAB's used(), you'd get a fairly
> accurate number of the allocated bytes of a thread. There's no
> intentional delay. The only "delay" would come from the fact that the
> _allocated_bytes field is only loaded with acquire semantics, but not
> written to with release semantics, so there might be a slight gap
> there due to lack of synchronization, by design.

Due to this unsynchronized access between amount of TLAB space
allocated and current TLAB's used, it might also happen that the
reported number of bytes allocated jumps backwards intermittently.

E.g. if you have multiple readings of that bean:

reading-1 = JavaThread::_allocated_bytes (=1000) + TLAB::used() for
TLAB X (=3000)  -> 4000

reading-2 = JavaThread::_allocated_bytes (=1000) + TLAB::used() for
TLAB X+1 (=0) -> 1000

I.e. between the reading of the old value of allocated so far and
reading TLAB's used() the thread retired a TLAB and allocated a new
one. Or the new value for TLAB::used() X+1 just got visible to the CPU
reading the data before the new value of JavaThread::_allocated_bytes.

Thanks,
  Thomas