G1 trace humongous allocations

[charlie hunt]

AFAIK, there is not a JVM command line option that will dump the information you are looking.

Although I haven’t tried it, I have heard that there is a JFR (Java Flight Recorder) event for what the JVM in general considers large object allocations, (i.e. allocations to go on what’s called the “slow path”).  You can use JFR, which is part of Java Mission Control, you’ll need to be on JDK 7u40+, iirc.

To use JFR / Mission Control in production environments you have to have a license, or some kind of purchased support for it.  But, it is free to use in non-production environments.

I have yet to use JFR / Mission Control.  But, it’s on my short list.  So, I wouldn’t be the person to ask how to use Mission Control and JFR to collect the information you’re looking for.

hths,

charlie ...

On Dec 18, 2013, at 10:51 AM, Wolfgang Pedot <wolfgang.pedot at finkzeit.at> wrote:

> Hi,
> 
> is there a way to trace humongous allocations when using G1? I have a 
> productive application (7u45, ~16GB Heap-Size) and every now and again 
> there are humongous allocations ranging from ~6-60MB. I know this from 
> the output of -XX:+G1PrintRegionLivenessInfo. For example:
> 
> ###   HUMS 0x000000073a000000-0x000000073a800000    8388608    8388608 
>         0       3424136.5
> ###   HUMC 0x000000073a800000-0x000000073b000000    8388608    8388608 
>         0        637263.3
> ###   HUMC 0x000000073b000000-0x000000073b800000    8388608    8388608 
>         0        276982.8
> ###   HUMC 0x000000073b800000-0x000000073c000000    8388608    8388608 
>         0      10190518.0
> ###   HUMC 0x000000073c000000-0x000000073c800000    8388608    8388608 
>         0      20046222.4
> ###   HUMC 0x000000073c800000-0x000000073d000000    6580624    6580624 
>         0       1077287.7
> 
> This is taken from the Post-Marking Phase output of the GC-Log, usually 
> a similar block repeats a couple of times indicating that either 
> something big has been copied or its a repeated request. On a normal day 
> there are one or two region-dumps containing HUMS/HUMC entries so they 
> are fairly rare and judging from the logs they are all rather 
> short-lived. I can pinpoint the allocations to a timewindow of 30-90min 
> but so far have been unsuccessful to find something specific in the logs 
> and there are hundrets of sessions on several different interfaces that 
> could cause this. Its not really an issue but I dont see why my code 
> should produce objects/arrays this large so I would like to know what 
> code or at least thread did as it could also be a library.
> 
> I cant go ahead and dump the heap every half hour in the hope to catch 
> such an object while its alive, is there a way G1 could log which thread 
> allocated the object or a stacktrace?
> 
> kind regards
> Wolfgang Pedot
> 
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use