G1 trace humongous allocations

charlie hunt charlesjhunt at gmail.com
Wed Dec 18 13:53:48 PST 2013 

One could argue there isn't an explicit probe point for large object
allocations.  But, there is one for object allocations outside of a TLAB.
 And, this is the one that I had in mind.  You can find it in the source
file Kris mentioned above,
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/0025a2a965c8/src/share/vm/gc_interface/collectedHeap.inline.hpp
on
line 154 in the
method CollectedHeap::common_mem_allocate_noinit(KlassHandle klass, size_t
size, TRAPS).  The probe is this piece of
code: AllocTracer::send_allocation_outside_tlab_event(klass, size *
HeapWordSize);

Based on the trace.xml
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/0025a2a965c8/src/share/vm/trace/trace.xml,
on line 347, you should find the "AllocObjectOutsideTLAB" event name.

So, if you use JFR, and subscribe to that AllocObjectOutsideTLAB event, you
will should see object allocations that occur outside a TLAB, and that
event will include the size of the allocation, and include a stack trace
along with class and thread involved.

Though it's not *exactly* what Wolfgang may be looking for, it narrows down
the possibilities and the intrusiveness of getting the information won't be
nearly as great as with a profiler such as VisualVM.  However, remember the
license restrictions on JFR/Mission Control.

In the past I've done as Kris suggested too where I've built a custom /
modified version of OpenJDK to print this information.  But, hacking
OpenJDK and building OpenJDK, and then feeling safe about running that
modified version is not for everyone. ;-)  Hence, I didn't mention that
path.

hths,

charlie ...



On Wed, Dec 18, 2013 at 2:37 PM, Krystal Mok <rednaxelafx at gmail.com> wrote:

> 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/6f176b53/attachment.html

More information about the hotspot-gc-use mailing list