P3
I noticed this when looking at test results from test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java.
When we specify a path-to-gc-roots parameter to JFR.dump and the recording had been started with a cutoff, the cutoff is ignored. This means we can spend a lot of time in the dump command.
I followed this strangeness down to :
`DCmdDump.dump(PlatformRecorder, Recording, String, String, Long, Boolean, Instant, ...) (jdk.jfr.internal.dcmd)` ->
`DCmdDump.newSnapShot(PlatformRecorder, Recording, Boolean) (jdk.jfr.internal.dcmd)` ->
`DCmdDump.newSnapShot(PlatformRecorder, Recording, Boolean) (jdk.jfr.internal.dcmd)` ->
PlatformRecording.newSnapshotClone(String, Boolean) (jdk.jfr.internal)
where we create a snapshot `PlatformRecording` clone from the original `PlatformRecording` that was found to be the recording-to-dump based on the "name" parameter give to `JFR.dump`.
The cloned PlatformRecording - which is the one that is eventually dumped - may not get the settings as a copy from the original recording; instead, a clean set of settings may be created here: `OldObjectSample.createSettingsForSnapshot`
As a result, the dump will use the default cutoff parameter of "infinite" .
I have no idea whether this is intentional. In TestJcmdDumpPathToGCRoots, we seem to expect that the gc root paths are dumped even when specifying cutoffs (see https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java#L64C1-L64C96)
There is also this mysterious comment here: https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java#L62 - which seems to indicate something about parameter order?
If it is intentional, comments would be very helpful; if not, a fix would be nice.
When we specify a path-to-gc-roots parameter to JFR.dump and the recording had been started with a cutoff, the cutoff is ignored. This means we can spend a lot of time in the dump command.
I followed this strangeness down to :
`DCmdDump.dump(PlatformRecorder, Recording, String, String, Long, Boolean, Instant, ...) (jdk.jfr.internal.dcmd)` ->
`DCmdDump.newSnapShot(PlatformRecorder, Recording, Boolean) (jdk.jfr.internal.dcmd)` ->
`DCmdDump.newSnapShot(PlatformRecorder, Recording, Boolean) (jdk.jfr.internal.dcmd)` ->
PlatformRecording.newSnapshotClone(String, Boolean) (jdk.jfr.internal)
where we create a snapshot `PlatformRecording` clone from the original `PlatformRecording` that was found to be the recording-to-dump based on the "name" parameter give to `JFR.dump`.
The cloned PlatformRecording - which is the one that is eventually dumped - may not get the settings as a copy from the original recording; instead, a clean set of settings may be created here: `OldObjectSample.createSettingsForSnapshot`
As a result, the dump will use the default cutoff parameter of "infinite" .
I have no idea whether this is intentional. In TestJcmdDumpPathToGCRoots, we seem to expect that the gc root paths are dumped even when specifying cutoffs (see https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java#L64C1-L64C96)
There is also this mysterious comment here: https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/test/jdk/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java#L62 - which seems to indicate something about parameter order?
If it is intentional, comments would be very helpful; if not, a fix would be nice.