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 _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
