The existing mechanism is problematic in that it is racy; it reads TLAB pointers updated by another thread. It attempts to parry for reading inappropriate values by comparing the used_bytes against the max_tlab_size, to avoid reporting values considered entirely off. A safer means would be to pick up and report only the bytes the owner of the tlab reported already (i.e. _allocated_bytes), but this would mean the reported value would trail by one tlab, and the impact of doing this is currently unknown. It could also involve introducing some protocol in how the threads publish their values from their TLABs. Or perhaps this race, with its current workaround, can be considered benign?
The problems with this function became manifest withJDK-8260046. JDK-8267579 introduced a workaround to help reduce the overall impact of this problem, as seen in general testing.
The problems with this function became manifest with
- relates to
-
JDK-8267579 Thread::cooked_allocated_bytes() hits assert(left >= right) failed: avoid underflow
-
- Resolved
-
-
JDK-8260046 Assert left >= right in pointer_delta() methods
-
- Resolved
-
-
CODETOOLS-7902998 jcstress: Add new ThreadMXBeanAlloc test
-
- Closed
-