-
Enhancement
-
Resolution: Fixed
-
P4
-
17, 21, 22
-
b26
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8361287 | 21.0.9 | Aleksey Shipilev | P4 | Resolved | Fixed | master |
It is quite alone in its hunger. The rest of the tests together accumulate just ~50mb of libc retention.
The buffer does a stress test of the BufferNodeAllocator. Four "mutator threads" race four "gc threads". Mutator threads allocate buffers, GC threads release them. No processing is done on the buffers; this seems to be purely a test of the allocator and its freelist mechanism. The memory footprint of this test depends on the number of retained free buffers in the allocator. The allocator bulk-releases free buffers triggered by a free-count-threshold. On my box, the number of free items is 100k..200k.
To me, its not clear whether the fact that so many freelist items exist indicates a problem with the allocator itself. To me it looks like the free list should be drained if there are more than 10 items in this list.
But each buffer is capacity=1024, *sizeof(void*)+header, so 8KB+x, and with 100..200k of those alive it explains the NMT-reported malloc footprint of ~1.5GB. An easy fix is to reduce the size of this buffer; since they are not processed, their size should not matter. It may be good to keep them above a cache line size though to prevent false sharing during this test.
- backported by
-
JDK-8361287 gtest high malloc footprint caused by BufferNodeAllocator stress test
-
- Resolved
-
- duplicates
-
JDK-8320366 gtest/GTestWrapper.java failed os_linux.glibc_mallinfo_wrapper_vm
-
- Closed
-
- relates to
-
JDK-8213352 Separate BufferNode allocation from PtrQueueSet
-
- Resolved
-
-
JDK-8320366 gtest/GTestWrapper.java failed os_linux.glibc_mallinfo_wrapper_vm
-
- Closed
-
- links to
-
Commit openjdk/jdk/abf2e490
-
Commit(master) openjdk/jdk21u-dev/dbed35f4
-
Review openjdk/jdk/16845
-
Review(master) openjdk/jdk21u-dev/1931