Scrubbing recording data by datetime

Erik Gahlin erik.gahlin at oracle.com
Sun Oct 5 15:29:36 UTC 2025


Hi Yasumasa,

As you’ve probably noticed, this question came up when we added ‘jfr scrub’.

Before adding flags, it would help to understand your concrete use case. Why do you need to select a datetime interval on an existing recording file? If you can describe the underlying goal, we can design the right option.

For example, if the intent is to split a large recording into smaller pieces - say, to send them as attachments - then a size-based approach might be a better fit than a time-based one, e.g. ‘jfr disassemble --max-size 5000000’

JFR.dump can select an interval precisely because the user knows the current wall-clock time, so choosing start and end is straightforward. With an offline file like dump.jfr, absolute times are usually not obvious, and time zones can complicate matters further.

Erik

Confidential – Oracle Internal
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Yasumasa Suenaga <suenaga at oss.nttdata.com>
Sent: Saturday, October 4, 2025 4:02 AM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Cc: yasuenag at gmail.com <yasuenag at gmail.com>
Subject: Scrubbing recording data by datetime

Hi all,

I want to propose to add a feature to scrub recording data by datetime in `jfr scrub` command.

CSR of `jfr scrub` [1] says a possibility to dump the last 30 seconds for later analysis. I completely agree with this use case, but `jfr scrub` hasn't yet had a feature to scrub recording data to datetime. Currently we can scrub recording data by thread, event, and categories. However it is more useful if all of contents which emitted in the time window we want to focus especially the analyst doesn't know what happened yet.


I think we can add both `--start` and `--end` commandline option to `jfr scrub` command for this purpose.
Implementation POV, I think we can implement it easily with `RecordingFile::write` API.

I think it needs CSR because to add new commandline options to `jfr` command, so I want to hear your comments before to work.


Thanks,

Yasumasa


[1] https://bugs.openjdk.org/browse/JDK-8271585
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20251005/d631df52/attachment.htm>


More information about the hotspot-jfr-dev mailing list