JMC-7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks

[jbachorik]

Currently, the JFR recordings created by the JMC writer will have the start ticks set to the same value as the start timestamp. This will cause problems with the duration calculation which is using directly System.nanoTime() and as such the resulting value will be rather nonsensical.

This PR adds two new recording settings - startTicks and duration which can be used to write a JFR recording with correct values set. If the user does not set those settings startTicks will be set to the value of System.nanoTime() at the moment the recording is started (a Recording instance is created) and duration will be computed as a diff between the current value of System.nanoTime() and startTicks.

---

Progress

• [x] Commit message must refer to an issue
• [ ] Change must be properly reviewed (1 review required, with at least 1 Committer)

Issue

• JMC-7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jmc pull/412/head:pull/412
$ git checkout pull/412

Update a local copy of the PR:
$ git checkout pull/412
$ git pull https://git.openjdk.org/jmc pull/412/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 412

View PR using the GUI difftool:
$ git pr show -t 412

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jmc/pull/412.diff

[bridgekeeper[bot]]

:wave: Welcome back jbachorik! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[mlbridge[bot]]

Webrevs

• 02: Full - Incremental (dfedb3f7)
• 01: Full - Incremental (d0e5225d)
• 00: Full (faf5a14f)

[RealCLanger]

Hi, I made a few initial comments, will try to review it in the next days. One other hint: Maybe you could update your branch with current master?

[RealCLanger]

And one more thing: In RecordingImpl::writeCheckpointEvent, I see that a duration is calculated as well. Shouldn't it then maybe also rather use the value of duration if it is > 0?

[thegreystone]

@jbachorik - anything left before taking this one? See @RealCLanger's comment.

[jbachorik]

Hi Christoph,

Regarding the varint signedness - it is a bit of grey area. The encoding used in JFR and this writer impl is not preserving sign - but, IMO, it should be possible to write a Java long number in its entirety such that when I write out -1 and read it back to Java I would get -1, although it is really treated as 0xffffffffffffffff by the writer/parser. But changing that behaviour would require changes in JFR and JMC as in both places the number of bytes comprising a long number is limited to 9.

Regarding the usage - we are not using the writer in the JMC project yet. However, we are using it at Datadog to generate 'on-the-fly' recordings for tests where we can create really exotic combinations of events to make sure our backend can deal with them.

[openjdk[bot]]

@jbachorik This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

7855: JFR Writer incorrectly uses epoch nanoseconds as the start ticks

Reviewed-by: clanger

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 20 new commits pushed to the master branch:

• 1696e03a1fddb9cc68d32bf21a281ef24366e552: 7902: UseCompressedOopsRule has flipped comparison
• 9d99d8819e020b98f11ae6a8d2950d8fbed00382: 7910: Fix spotless finding after JMC-7903
• 7cd2f3e730480c833930e36951f8658b4addead4: 7903: FastAccessNumberMap is slow for sparse values
• e6778b191878c68d7c72af93a1a99ee49e0e7caa: 7813: Unable to open Help page in macOS M1 when JMC started with JDK11
• 359f6abe17d81131e6091fa5596d6f45f56613d7: 7870: JMC 8.3.0 Update Site Pages require changes
• de649008bf4b5eec761c2487e0c8c9069ff5ab31: 7892: JMC Automated UI MasterPasswordTests is failing
• 9b8e04494384400a902ad6e4a22587764576e5a7: 7812: Unable to open links from Automated Result analysis page
• 0b91cf1df15b65eec27ad3cf4d64f2c015291ea6: 7896: Merge changes of 8.2.1 into master branch
• b29aefc2fc59f8fe00d750fb0f0681c351b49ae1: 7074: Smart pruning of graphs to make it possible to sensibly render larger graphs
• 9a46d3ec54e80d310b27b73ceb4c84deda9ead47: 6757: Selector for attribute in the flame graph
• ... and 10 more: https://git.openjdk.org/jmc/compare/056139f05ae8406c7203a68543c9e9041240427f...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@RealCLanger) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

[jbachorik]

/integrate

[openjdk[bot]]

@jbachorik Your change (at version dfedb3f76c8f50403d14a7ee8d22ab5e05fbc2f8) is now ready to be sponsored by a Committer.

[RealCLanger]

/sponsor

[openjdk[bot]]

Going to push as commit b1494d2cd81a5225e8bd79a55c507ef577476c38. Since your change was applied there have been 20 commits pushed to the master branch:

• 1696e03a1fddb9cc68d32bf21a281ef24366e552: 7902: UseCompressedOopsRule has flipped comparison
• 9d99d8819e020b98f11ae6a8d2950d8fbed00382: 7910: Fix spotless finding after JMC-7903
• 7cd2f3e730480c833930e36951f8658b4addead4: 7903: FastAccessNumberMap is slow for sparse values
• e6778b191878c68d7c72af93a1a99ee49e0e7caa: 7813: Unable to open Help page in macOS M1 when JMC started with JDK11
• 359f6abe17d81131e6091fa5596d6f45f56613d7: 7870: JMC 8.3.0 Update Site Pages require changes
• de649008bf4b5eec761c2487e0c8c9069ff5ab31: 7892: JMC Automated UI MasterPasswordTests is failing
• 9b8e04494384400a902ad6e4a22587764576e5a7: 7812: Unable to open links from Automated Result analysis page
• 0b91cf1df15b65eec27ad3cf4d64f2c015291ea6: 7896: Merge changes of 8.2.1 into master branch
• b29aefc2fc59f8fe00d750fb0f0681c351b49ae1: 7074: Smart pruning of graphs to make it possible to sensibly render larger graphs
• 9a46d3ec54e80d310b27b73ceb4c84deda9ead47: 6757: Selector for attribute in the flame graph
• ... and 10 more: https://git.openjdk.org/jmc/compare/056139f05ae8406c7203a68543c9e9041240427f...master

Your commit was automatically rebased without conflicts.

[openjdk[bot]]

@RealCLanger @jbachorik Pushed as commit b1494d2cd81a5225e8bd79a55c507ef577476c38.

:bulb: You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.