AllocationRequiringGC stacktrace precision

[Markus Gronlund]

Hi Milan,

Thanks for noticing the issue with the JfrConditionalFlushWithStacktrace. 

I would have thought it was placed under a should_commit() branch at the site, but it looks like that is not the case.

I will fix this.

Thanks again
Markus

-----Original Message-----
From: Milan Mimica <milan.mimica at gmail.com> 
Sent: den 20 juni 2019 17:54
To: Markus Gronlund <markus.gronlund at oracle.com>
Cc: hotspot-jfr-dev at openjdk.java.net
Subject: Re: AllocationRequiringGC stacktrace precision

Hi Markus

I didn't succeed to reproduce this in a simple program.

But while examining the code I found something suspicious (and unrelated to this topic) that I want to check. In ObjectMonitor::enter, there is JfrConditionalFlushWithStacktrace. It *unconditionally* creates the stack trace and stores in a thread-local.

JfrConditionalFlushWithStacktrace(Thread* t) :
JfrConditionalFlush<Event>(t), _t(t), _owner(false) {
    if (Event::has_stacktrace() && jfr_has_stacktrace_enabled(Event::eventId)) {
        _owner = jfr_save_stacktrace(t);

this "if" here statically evaluates to "true". Now, I don't know how ObjectMonitor works, or why is the stack trace stored at this point, but to me it looks like a "jfr_is_event_enabled(Event::eventId)" is missing here.
Is this stack-trace of any use if the event is not enabled? Is it just a waste of CPU?


On Fri, 14 Jun 2019 at 00:17, Markus Gronlund <markus.gronlund at oracle.com> wrote:
>
> Hi Milan,
>
> Would you be able to create a small reproducer that demonstrates this behavior you are seeing?
>
> It would help a lot.
>
> Thanks in advance
> Markus
>
>
> -----Original Message-----
> From: Milan Mimica <milan.mimica at gmail.com>
> Sent: den 13 juni 2019 21:33
> To: hotspot-jfr-dev at openjdk.java.net
> Subject: AllocationRequiringGC stacktrace precision
>
> Hello List
>
> I've been using JFR Java API to track allocations that are of interests to me. I'm focused on large allocations that trigger AllocationRequiringGC event. I came across this event I can't explain:
>
> This is the top of the stack trace
> (jdk.jfr.consumer.RecordedStackTrace#getFrames):
> at java.lang.Integer#valueOf line: 1050
>
> and jdk.jfr.consumer.RecordedObject#getValue("size") says it allocated about 8MB.
>
> Happened using version 11.0.3, with G1.
> This makes me wonder how reliable the stack-traces that come with events are? I've been looking at hotspot code and I would say that the java thread is blocked while waiting for allocation and it's safe to take a snapshot of its stack. I'm I missing something?
>
>
> --
> Milan Mimica



--
Milan Mimica