8253235: JFR.dump does not respect maxage parameter

[kvergizova]

JFR.dump command creates a clone of the original recording, but maxage and maxsize parameters are not copied to the clone in PlatformRecording.newSnapshotClone().
When PlatformRecording.appendChunk() is called for the clone to append the latest data, trimToAge() and trimToSize() are not performed because maxAge and maxSize are not set.
Therefore the clone sometimes dumps outdated chunks to the disk.

Testing:
jdk/jdk/jfr/*

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8253235: JFR.dump does not respect maxage parameter

Reviewers

• Erik Gahlin (@egahlin - Reviewer)

Download

$ git fetch https://git.openjdk.java.net/jdk pull/239/head:pull/239
$ git checkout pull/239

[bridgekeeper]

👋 Welcome back kvergizova! 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.

[openjdk]

@kvergizova The following label will be automatically applied to this pull request: hotspot-jfr.

When this pull request is ready to be reviewed, an RFR email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label (add|remove) "label" command.

[mlbridge]

Webrevs

• 00: Full (10722d3)

[mlbridge]

Mailing list message from Ekaterina Vergizova on hotspot-jfr-dev:

Gentle reminder

-----Original Message-----
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.java.net> On Behalf Of Ekaterina Vergizova
Sent: Friday, September 18, 2020 1:23 PM
To: hotspot-jfr-dev at openjdk.java.net
Subject: RFR: 8253235: JFR.dump does not respect maxage parameter

JFR.dump command creates a clone of the original recording, but maxage and maxsize parameters are not copied to the clone in PlatformRecording.newSnapshotClone(). When PlatformRecording.appendChunk() is called for the clone to append the latest data, trimToAge() and trimToSize() are not performed because maxAge and maxSize are not set. Therefore the clone sometimes dumps outdated chunks to the disk.

Testing:
jdk/jdk/jfr/*

-------------

Commit messages:
- 8253235: JFR.dump does not respect maxage parameter

Changes: https://git.openjdk.java.net/jdk/pull/239/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=239&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8253235
Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
Patch: https://git.openjdk.java.net/jdk/pull/239.diff
Fetch: git fetch https://git.openjdk.java.net/jdk pull/239/head:pull/239

PR: https://git.openjdk.java.net/jdk/pull/239

[openjdk]

@kvergizova 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:

8253235: JFR.dump does not respect maxage parameter

Reviewed-by: egahlin

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 442 new commits pushed to the master branch:

• cb7701b: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid)
• 4ffed32: 8254940: AArch64: Cleanup non-product thread members
• cd66e0f: 8253877: gc/g1/TestGCLogMessages.java fails - missing "Evacuation failure" message
• e76de18: 8223051: support loops with long (64b) trip counts
• e9be2db: 8253453: SourceFileInfoTable should be allocated lazily
• e10b538: 8243962: Various JVM TI tests time out using JFR on Windows
• a1a3e9d: 8254882: ZGC: Use static_assert instead of guarantee
• 8edc2f0: 8254912: ZGC: Change ZCollectionInterval type to double
• 672f566: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing
• 98a395a: 8254880: ZGC: Let ZList iterators be alias templates
• ... and 432 more: https://git.openjdk.java.net/jdk/compare/33f8e7022ca912af991b5aa94d0da212b3a121e3...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 (@egahlin) 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).

[kvergizova]

/integrate

[openjdk]

@kvergizova
Your change (at version 10722d3) is now ready to be sponsored by a Committer.

[VladimirKempik]

/sponsor

[openjdk]

@VladimirKempik @kvergizova Since your change was applied there have been 442 commits pushed to the master branch:

• cb7701b: 8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid)
• 4ffed32: 8254940: AArch64: Cleanup non-product thread members
• cd66e0f: 8253877: gc/g1/TestGCLogMessages.java fails - missing "Evacuation failure" message
• e76de18: 8223051: support loops with long (64b) trip counts
• e9be2db: 8253453: SourceFileInfoTable should be allocated lazily
• e10b538: 8243962: Various JVM TI tests time out using JFR on Windows
• a1a3e9d: 8254882: ZGC: Use static_assert instead of guarantee
• 8edc2f0: 8254912: ZGC: Change ZCollectionInterval type to double
• 672f566: 8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing
• 98a395a: 8254880: ZGC: Let ZList iterators be alias templates
• ... and 432 more: https://git.openjdk.java.net/jdk/compare/33f8e7022ca912af991b5aa94d0da212b3a121e3...master

Your commit was automatically rebased without conflicts.

Pushed as commit a0382cd.

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