January 2022 - hotspot-jfr-dev

RFR: 8279646: JFR: Remove recursive call in jdk.jfr.internal.Control
by Erik Gahlin 11 Jan '22

11 Jan '22

Hi, Could I have a review of a fix that removes an endless recursive call. The reason this has gone unnoticed is because the Control::getValue() method is never invoked for VM events. The getValue() method is invoked when a new SettingControl is instantiated for a user-defined event, see line 177 in EventControl.java, which never happens for native events. The method is also invoked when fetching the default value, see line 69 in Control.java, but native events provides them directly, when instantiated, for example in EventControl::defineThreshold, so the bug has never been exposed. That said, getValue() should delegate like the other methods, i.e combine(Set) and setValue(String), in the Control class. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6998/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6998&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279646 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6998.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6998/head:pull/6998 PR: https://git.openjdk.java.net/jdk/pull/6998

2 2

RFR: 8279645: JFR: The cacheEventType in Dispatcher is never assigned
by Erik Gahlin 10 Jan '22

10 Jan '22

Hi, Could I have review of a bug fix that assign the last event type to the cache when dispatching events for event streaming. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6996/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6996&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279645 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/6996.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6996/head:pull/6996 PR: https://git.openjdk.java.net/jdk/pull/6996

2 2

RFR: 8279643: JFR: Explain why path is sometimes missing from FileRead and FileWrite events
by Erik Gahlin 10 Jan '22

10 Jan '22

Hi, Could I have a review of an enhancement that explains why the path fields for the FileRead and FileWrite events sometimes miss a value. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6995/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6995&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279643 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6995.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6995/head:pull/6995 PR: https://git.openjdk.java.net/jdk/pull/6995

2 2

RFR: 8279642: JFR: Remove unnecessary creation of Duration and Instant objects
by Erik Gahlin 10 Jan '22

10 Jan '22

Hi, Could I have review of an enhancement that removes a few unnecessary allocations when consuming JFR events. It's quite common that events have no duration and there is no need to recalculate an instant twice. I also removed an unnecessary throws clause. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/6994/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6994&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279642 Stats: 10 lines in 2 files changed: 6 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/6994.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6994/head:pull/6994 PR: https://git.openjdk.java.net/jdk/pull/6994

2 2

[jdk18] RFR: 8279398: jdk/jfr/api/recording/time/TestTimeMultiple.java failed with "RuntimeException: getStopTime() > afterStop"
by Erik Gahlin 10 Jan '22

10 Jan '22

Hi, Could I have review of a fix of a regression introduced with "JDK-8268297: jdk/jfr/api/consumer/streaming/TestLatestEvent.java times out" https://bugs.openjdk.java.net/browse/JDK-8268297 Bumping the timestamp in native, if the timestamp has not changed, ensures that chunks gets a strictly increasing start time, which is needed for event streaming to order chunks chronologically. Problem is that tests, and probably users as well, expect that the start/stop time of a recording never exceeds what a later invocation to Instant.now() returns, for example: Recording a = new Recording(); a.start(); // first chunk begins a.stop(); // first chunk ends Recording b = new Recording(); b.start(); // second chunk begins, where time stamp is taken and possibly bumped with a nanosecond. Instant now = Instant.now(); if (now.isBefore(b.getStartTime())) { System.out.println("WAT"); } This can happen on Windows where the clock has low resolution, so Recording::start() may finish execution without a clock change. The fix is to let methods that creates a new chunk spin until the clock has catched up. To verify the fix, I modified the test jdk/jdk/jfr/api/recoding/time/TestTimeMultiple.java so it executes code similar to above 100 times per test and then ran the test 200 times without failures. Without the fix, failures were frequent. Technically, it's not necessary for all places to use Utils::getChunkStartNanos() instead of JVM::getChunkStartNanos(), but it seemed more prudent to never use the low level function, which can in some circumstances lead to incorrect behavior. Thanks Erik ------------- Commit messages: - Remove whitespace - Update comment - Initial Changes: https://git.openjdk.java.net/jdk18/pull/84/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk18&pr=84&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8279398 Stats: 61 lines in 3 files changed: 31 ins; 23 del; 7 mod Patch: https://git.openjdk.java.net/jdk18/pull/84.diff Fetch: git fetch https://git.openjdk.java.net/jdk18 pull/84/head:pull/84 PR: https://git.openjdk.java.net/jdk18/pull/84

2 2