RFR(S): 8238375: JFR Test TestJcmdStartFlushInterval is not run

Erik Gahlin erik.gahlin at oracle.com
Sun Feb 2 16:30:58 UTC 2020


Hi,

I should get my Eclipse workspace in order :)

We removed getFlushInterval/setFlushInterval from the API because we didn’t think the methods were needed [1]. JFR has a flush interval of 1 s by default. Initially we had a higher number. 

We kept the options for -XX:StartFlightRecording and jcmd, so users would have a workaround if they would run into performance issues.

Change looks good, but could you modify the interval to 2s, so the test verifies that a change has actually occurred. 

No need to send out new webrev.

Thanks
Erik

[1] https://bugs.openjdk.java.net/browse/JDK-8236264


> On 2 Feb 2020, at 16:47, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi,
> 
> when culling errors in my Eclipse IDE, I found an issue with JFR test TestJcmdStartFlushInterval. It can never have been run at all, because it contains the jtreg annotation "@run main/othervm jdk.jfr.jcmd.TestJcmdStartReadOnlyFile" and hence runs a different test.
> 
> The wrong run directive shadows an actual compile time error in the test. The method jdk.jfr.Recording::getFlushInterval is package private, so to be able to invoke it in the test that obviously lives in another package, it has to be made accessible via reflection. Here would be the fix. I, however, don't know why getFlushInterval is package private and whether it couldn't/shouldn't be made a public API.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8238375
> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8238375.0/
> 
> Cheers
> Christoph
> 



More information about the hotspot-jfr-dev mailing list