-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8351925: JFR: Microsecond time format precision for JFR tool #24029
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
👋 Welcome back shade! A progress list of the required criteria for merging this PR into |
|
❗ This change is not yet ready to be integrated. |
|
The default mode (PrettyWriter) aims to present human-readable output, striking a balance between clarity and concision. For more detailed information, including timestamps and time spans with nine-digit precision, |
I understand, no pressure. I do see folks in my vicinity (myself included) reaching for human-readable output for quick and dirty analysis. Very often that human-readable output is really great to quickly capture what is going on. At the scales we operate on, it is useful to see microseconds to correlate events happening within a millisecond. Switching to JSON does work, but it feels like an unnecessary friction. Microsecond precision for timings is not uncommon. For example, Linux perf tools routinely report ISO 8601 timestamps with microsecond precision. |
The output from PrettyWriter is used by RecordedEvent::toString(), so it serves more than one purpose. What is the primary friction you see in --json? The verbose stack traces, too much precision, or the need to specify a command-line flag? |
JSON is too verbose for human consumption. I think this is mostly due to stack traces, but there are also other parts that are relatively noisy. So I cannot easily show the pair of events in a bug report / chat message to show a particular piece of JFR-captured info, without first truncating the output. Compare the human-readable output for the same event: ...and JSON one: |
The stack trace can be removed with When If the use case is to copy detailed human-readable output into a bug report, perhaps there should be a switch that prints numbers and timestamps in full precision. Six digits might not be sufficient for timestamps, and then there are durations as well. I created a prototype that prints durations and timestamps with nanosecond precision, as well as the full value of bytes, bits, and percentages. |
This works for me! Feel free to take over this RFE, or I can close this one as duplicate of another RFE for |
|
Closed in favor of JDK-8353614. |
Currently, JFR tool formats the times with millisecond precision:
In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful.
After the patch:
I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately.
Progress
Issue
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/24029/head:pull/24029$ git checkout pull/24029Update a local copy of the PR:
$ git checkout pull/24029$ git pull https://git.openjdk.org/jdk.git pull/24029/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 24029View PR using the GUI difftool:
$ git pr show -t 24029Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/24029.diff
Using Webrev
Link to Webrev Comment