JFR Recordings Missing Periodic Events

Carter Kozak ckozak at ckozak.net
Thu Dec 14 22:06:33 UTC 2023


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


More information about the hotspot-jfr-dev mailing list