JDK-8200296 : JTREG tests (functionality) for CodeHeap State Analytics
Type:Enhancement
Component:hotspot
Sub-Component:compiler
Affected Version:11,12
Priority:P4
Status:In Progress
Resolution:Unresolved
OS:generic
CPU:generic
Submitted:2018-03-27
Updated:2019-07-19
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
Create some tests to verify basic functionality of RFE JDK-8198691.
Comments
I have changed the fix version to "tbd". There are two reasons: time constraints and general doubts re the usefulness of such tests. See my previous comments.
19-07-2019
Sorry for writing but not transporting the message!
When I created this bug, I assumed that, because the feature was new, test coverage would be zero. So the plan was to create tests which trigger the various functions and check if the triggered processing ends without error, creating "some" output. That part is obviously covered by some generic tests.
As detailed above, analysing the created output is cumbersome and, at least as important, fragile. I do not want to create fragile tests which erratically produce false positives.
16-01-2019
I am not sure I understand how more issues found by stress tests making it more difficult to write meaningful functional tests, could you please elaborate?
deferred to 13.
15-01-2019
Igor,
to be honest: no, I'm not actively working on this. I have it in my work list, but other items tend to be flagged with higher importance. It's not that the feature lingers around totally untested. Refer to JDK-8216314 for an example.
The more of those stress tests pop up (with issues), the more difficult it becomes to write meaningful functional tests. Just as a thought: I would like to create a well-controlled, predictable CodeHeap layout, use CodeHeap state analytics to print it, and finally compare the output with the expectation. You see, it's just pattern matching with some tolerance re. variations. :-)
In essence: could we please defer again?
15-01-2019
[~lucy] Lutz, we are again close to GA, are you actively working on this? do you expect it to be ready soon?
14-01-2019
sure Lutz, deferred.
08-08-2018
Igor,
I'd prefer this to be deferred to 12. I have these tests on my task list. As often, higher priority items have been squeezed in recently. I'm not a friend of "quick shots", just to make the deadline.
Thanks,
Lutz
08-08-2018
[~lucy], with JDK 11 being in RDP2[1] and quite close to GA[2], do you think you will be able to integrate these tests in time? or should this be deferred to 12?
[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001669.html
[2] http://openjdk.java.net/projects/jdk/11/