G1 trace humongous allocations

[Wolfgang Pedot]

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