AllocationRequiringGC stacktrace precision

[Milan Mimica]

On Thu, Jun 20, 2019, 21:17 Erik Gahlin <erik.gahlin at oracle.com> wrote:

>
>
> > On 20 Jun 2019, at 17:54, Milan Mimica <milan.mimica at gmail.com> wrote:
> >
> > 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.
>
> Yes, It could be added at the end.
>
> Both default.jfc and profile.jfc however have the event enabled by
> default, but with a threshold, so the stack trace will only be taken if it
> is a longer latency. Adding the check will only benefit people who make
> their own configuration and opt-out of stack traces.
>

But what about what about when jfr recording hasn't been started at all?
The most common case. It only creates unnecessary overhead.



> The reason for the flush mechanism, is to prevent JFR from writing to disk
> (due buffers being flushed) when we have the monitor. If the buffer is soon
> to be filled, it is flushed before.
>
> Erik
>
>