RFR(S) Trace significant heap allocations

[Krystal Mok]

Hi Milan,

Is there an attachment with your email? I can't see it. It might have been
stripped. Could you try posting it again or upload it somewhere else and
post a link in this thread?

About the first flag, TraceLargerAllocations, we've implemented something
similar in Taobao's customized HotSpot, and a patch is available at [1].
Since it's extremely rare to see large objects in Java other than arrays,
we didn't bother to implement the feature for object instances other than
arrays. We didn't see an interest in the upstream for that kind of feature
so we didn't push it up.

On the other hand, though, in Oracle's implementation of Java Flight
Recorder, you do actually get stack traces for EventAllocObjectOutsideTLAB.
See these two screenshots of Java Mission Control [2] [3].

You're right that you can't set a size threshold for the trigger of that
event, but it shouldn't be hard to write a filter to only pickup the events
of your interest.

Regards,
Kris

[1]: http://jvm.taobao.org/images/7/76/Jvm_large_array_alloc_warnning.patch
[2]:
http://dl.iteye.com/upload/picture/pic/129879/915f8f72-6d0f-3086-be1c-9928e8e33f92.png
[3]:
http://dl.iteye.com/upload/picture/pic/129881/a4fbb380-ca4d-3b2d-89b9-7387282fe239.png


On Fri, Mar 28, 2014 at 4:51 PM, Milan Mimica <milan.mimica at infobip.com>wrote:

> Hello
>
> One of my concerns recently was tracking down large memory allocations
> which cause G1 GC to do a Full GC. So I came out with this patch, which
> adds two diagnostic options:
> 1) TraceLargerAllocations - logs every heap allocation larger that the
> specified size
> 2) G1TraceFullGCAllocations - logs allocations which trigger a STW Full GC
> I see that these two options could be submitted as separate patches, but
> before we discuss the details I'd like to be sure that I'm doing the right
> thing.
>
> I understand that there are already at least two ways to trace allocations
> - EventAllocObjectOutsideTLAB and bytecode instrumentation. They both lack
> some crucial features:
> The problem with EventAllocObjectOutsideTLAB is that you cannot set size
> threshold, you don't get the java stacktrace, and you get loads of other
> uninteresting things with -XX:+EnableTracing. I don't find it useful. The
> event system could be extended to support those, but that's a bigger
> undertake. And it's coded in XML(!!?).
>
> Bytecode instrumentation, on the other hand, is intrusive, ads overhead,
> and it's too complicated. Just think of it, it was easier for me to
> implement these two VM options than to even start fiddling with bytecodes.
> (Partly because you made the jvm too easy to build, good job!) Having a
> profiler constantly connected to an instance is also not feasible.
>
> I think these two options are generally useful for tracing GC problems,
> especially G1TraceFullGCAllocations. With full java stacktrace the
> developer has all the information needed to locate the problem which is
> otherwise very hard to locate.
>
> So could someone review the patch and provide feedback? First time posting
> here, so I need a sponsor obviously.
>
> Milan Mimica, Software Engineer / Team Leader
>
> Office: Mletacka 12/III, 52100 Pula, Croatia  |  Fax: +38552210979  |  Mobile:
> +385993061692
> Email: Milan.Mimica at infobip.com  |  Skype: mmimicaib
> www.infobip.com   /   GSMA Associate Member   /   Mobey Forum Member
> This message is private and confidential. Any views or opinions expressed
> are solely those of the author and do not necessarily represent those of
> Infobip d.o.o. If you have received this message in error, please notify us
> immediately via email to customer.support at infobip.com or telephone
> +442032864235.
>