JFR Recordings Missing Periodic Events

[Erik Gahlin]

Hi Carter,

t's not possible to guarantee that events will be available unless a RecordingStream is used, the period is everyChunk and the stop() method is used.

That said, it looks strange. You could try running with -Xlog:jfr+system+parser=info,jfr+periodic=debug and only enable the ThreadStatistics event:

recording.enable("jdk.JavaThreadStatistics").with("period", "1000 ms");

It might make it easier to diagnose.

Erik
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Carter Kozak <ckozak at ckozak.net>
Sent: Thursday, December 14, 2023 11:06 PM
To: hotspot-jfr-dev at openjdk.java.net <hotspot-jfr-dev at openjdk.java.net>
Subject: Re: JFR Recordings Missing Periodic Events

This behavior appears to be a bug introduced by https://github.com/openjdk/jdk/pull/12668
More specifically, I believe that the first recording completes as expected, however in subsequent recordings, this snippet makes an incorrect assumption:
https://github.com/egahlin/jdk/blob/11ae47e75e907d5ce2c9491cf789767d207614a2/src/jdk.jfr/share/classes/jdk/jfr/internal/periodic/BatchManager.java#L65-L70
> Batch batch = task.getBatch();
> // If new task, or period has changed, find new batch
> if (batch == null) {
>     batch = findBatch(task.getPeriod());
> }
> batch.add(task);

task.getBatch() may return a non-null batch which has been removed from the BatchManager between recordings, when all events are disabled. The periodic task is then added to this orphaned batch, not to be scheduled again.
This also results in a memory leak as the initial iteration over batches which clears periodic tasks doesn't execute on orphaned batches, so each update will write additional duplicate elements into the batch.
Assuming this exists to avoid iteration over batches within refresh, I think we should add a boolean flag to the Batch type to describe whether or not it is active, allowing us to retain the optimization without orphaning events or leaking memory.
Feedback on this proposed fix would be appreciated!

I'd be happy to take a shot at fixing this, I'd appreciate if someone could create a ticket that I might work against.

Thanks,
Carter Kozak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20231214/37650b8a/attachment.htm>