Last active
September 23, 2021 08:42
-
-
Save bric3/ce236e2c74860fd60f3aa542b5a800d0 to your computer and use it in GitHub Desktop.
Inspect pmap -X output of a java process, requires Java11, may not be 100% accurate
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
/* | |
Moved here => https://github.com/bric3/java-pmap-inspector | |
*/ | |
public class JavaPmapInspector { | |
public static void main(String[] args) throws IOException { | |
System.err.println("Go to:"); | |
System.err.println(" https://github.com/bric3/java-pmap-inspector"); | |
} | |
} | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi @hfu5,
This is a a good question. I do have have all the piece, but here's my understanding of the phenomena.
It appears on 64bit Linux systems when the program uses the malloc implementation of the glibc. And glibc happens to manage memory using a well known strategy that is called region based memory management (a region is also called arena).
These region are created by glibc to avoid contention, and this depends on the number of CPU. Calling
malloc
once or two in the same thread won't stress enough the native allocator, in order to see multiple arenas, the program really need to allocate a bunch of data inferior to the 64 MB threshold, and in a multithreaded fashion.Homnestly, I only saw those on running jvm processes in production. I couldn't reproduce it locally but I likely didn't tried hard enough, if you succeed I'll be happy to learn how you did it.
I started to write a blog post a while ago on this topic and I need to go back writing it.