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

Doerr, Martin martin.doerr at sap.com
Thu Dec 14 18:31:49 UTC 2017


Hi Thomas,

thanks for your input. We're currently testing the change. I haven't seen regressions in benchmarks running with G1 so far, but I think we will need to run more of them.

Best regards,
Martin


-----Original Message-----
From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] 
Sent: Donnerstag, 14. Dezember 2017 17:51
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-runtime-dev at openjdk.java.net
Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration

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