-
Bug
-
Resolution: Fixed
-
P4
-
15
-
b27
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8248103 | 16 | Fairoz Matte | P4 | Resolved | Fixed | team |
Some jdi tests use less strict checks when JFR is used. It is checked with
public boolean isJFR_active() {
String opts = argumentHandler.getLaunchOptions();
int jfrPos = opts.indexOf("-XX:+FlightRecorder");
if (jfrPos >= 0)
return true;
else
return false;
}
However, the JFR is always enabled but not started by default. The line which used to run tests with JFR is
"-XX:StartFlightRecording=dumponexit=true,maxsize=500M -XX:FlightRecorderOptions=repository=jfrrep"
So tests unaware of JFR threads. Also, the JDI with Graal as JIT should be broken in the same way.
It is needed to investigate how it really works.
public boolean isJFR_active() {
String opts = argumentHandler.getLaunchOptions();
int jfrPos = opts.indexOf("-XX:+FlightRecorder");
if (jfrPos >= 0)
return true;
else
return false;
}
However, the JFR is always enabled but not started by default. The line which used to run tests with JFR is
"-XX:StartFlightRecording=dumponexit=true,maxsize=500M -XX:FlightRecorderOptions=repository=jfrrep"
So tests unaware of JFR threads. Also, the JDI with Graal as JIT should be broken in the same way.
It is needed to investigate how it really works.
- backported by
-
JDK-8248103 nsk.share.jdi.Debugee.isJFR_active() is incorrect and corresponsing logic seems to be broken
- Resolved