RFR(XS): 8193521: glibc wastes memory with default configuration

[Doerr, Martin]

Hi,

I noticed that glibc uses many malloc arenas. By default, glibc allocates a new 128 MB malloc arena for every thread (up to a certain limit, by default 8 * processor count).
This is good for few threads which perform a lot of concurrent mallocs, but it doesn't fit well to the JVM which has its own memory management and rather allocates fewer and larger chunks.
(See glibc source code libc_malloc which calls arena_get2 in malloc.c and _int_new_arena in arena.c.)
Using only one arena significantly reduces virtual memory footprint. Saving memory seems to be more valuable for the JVM than optimizing concurrent mallocs.

I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc 2.15. I don't think that we still support older versions with jdk10/11.
Please review my proposal:
http://cr.openjdk.java.net/~mdoerr/8193521_glibc_malloc/webrev.00/

Running a VM on x86_64 with -Xmx128m -Xss136k -XX:MaxMetaspaceSize=32m -XX:CompressedClassSpaceSize=32m -XX:ReservedCodeCacheSize=64m showed
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
30572 d056149   20   0 1839880 125504  22020 S 103,7  0,8   0:05.09 java

After the change, I got it down to:
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
30494 d056149   20   0  406932 114360  22544 S 102,7  0,7   0:06.53 java

I'm not aware of performance critical concurrent malloc usages in the JVM. Maybe somebody else is?
Comments are welcome. I will also need a sponsor if this change is desired.

Best regards,
Martin