G1 trace humongous allocations

[Krystal Mok]

Hi guys,

I don't see a probe point for large object allocation in the OpenJDK 7u
code. If there is one, than it should have been in
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/0025a2a965c8/src/share/vm/gc_interface/collectedHeap.inline.hpp

The probe points that JFR uses should be all in the OpenJDK, so my guess is
that there isn't an event for large object allocation per se. That said, I
haven't used JFR in JDK7u45 yet, so take my words with a grain of salt.

There's supposed to be a imprecise object allocation profiler in JFR, which
records that type and stack trace of the object to be allocated when the
TLAB has to refill. But I just did a quick check in OpenJDK7u code and
didn't see the probe point for that, so it probably hasn't made it in yet.

If you can build OpenJDK yourself, then there is a patch that my colleague
and I did when I was in Taobao, specifically to log the kind of event you
have in mind.
The patch is here, under TAOBAOJDK-006:
http://jvm.taobao.org/index.php/Sc_jvm_customization .
The usage is mentioned here (from page 47):
http://www.slideshare.net/RednaxelaFX/jvm-taobao
The patch is made against HotSpot Express 20, which corresponds to JDK6u25.
It may need some tweaks to work on OpenJDK7u.

Anyway, you can always use other alternatives, like using the memory
profiler that comes with VisualVM, which will instrument your bytecode to
record type and stack trace info. These alternatives come with some
overhead, but it might be worth it just for catching the problem you're
having.

HTH,
- Kris


On Wed, Dec 18, 2013 at 11:58 AM, charlie hunt <charlesjhunt at gmail.com>wrote:

> 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
>
> _______________________________________________
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-gc-use/attachments/20131218/ae8ea48f/attachment.html