Native memory leak in StringTable::intern using G1

[Thomas Schatzl]

Hi,

On Tue, 2017-02-21 at 10:52 -0800, Will Bertelsen wrote:
> Hi All,
> 
> I've been experimenting with G1 in production and have noticed a
> large native memory leak that eventually exhausts all memory on the
> system. I ran it overnight with NMT enabled and this was the biggest
> offender:
> 
> [0x00007f86c31cf205] Hashtable<oopDesc*,
> (MemoryType)9>::new_entry(unsigned int, oopDesc*)+0x165
> [0x00007f86c35dd263] StringTable::basic_add(int, Handle, unsigned
> short*, int, unsigned int, Thread*)+0xd3
> [0x00007f86c35dd452] StringTable::intern(Handle, unsigned short*,
> int, Thread*)+0x182
> [0x00007f86c35dd921] StringTable::intern(oopDesc*, Thread*)+0x131
>                              (malloc=2628520KB +2601784KB #328565
> +325223)
> 
> 
> Has anyone seen this before?

This is just a workaround, but if the application runs for so long that
it never does a full gc or do a marking cycle (did it?), you could
manually trigger string table cleanup by issuing a system.gc with jmap
now and then.
If you set -XX:+ExplicitGCInvokesConcurrent, it will not be a stop-the-
world gc.

There is no equivalent to CMSTriggerInterval in G1 which starts a
regular concurrent collection cycle every now and then (which is
basically the same band-aid).

> Here is my java version and gc settings:
> 
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

You may want to update. While looking for something similar in the bug
tracker, I found e.g. https://bugs.openjdk.java.net/browse/JDK-8133193 
fixed in 8u72.

Thanks,
  Thomas