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

Thomas Schatzl thomas.schatzl at oracle.com
Thu Dec 14 16:51:17 UTC 2017


Hi,

On Thu, 2017-12-14 at 16:00 +0000, Doerr, Martin wrote:
> 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?

E.g. G1 remembered sets can be a huge malloc'ed memory consumer,
although it (also partially) caches allocations from malloc.

Afair malloc performance can already be a significant performance issue
in that area.

Thanks,
  Thomas



More information about the hotspot-runtime-dev mailing list