JDK-8322327 : Regression on J2dBench-vimg_copyarea-ZGC - Windows x64
Type:Bug
Component:hotspot
Sub-Component:compiler
Affected Version:23
Priority:P4
Status:Closed
Resolution:Not an Issue
OS:linux
CPU:x86_64
Submitted:2023-12-18
Updated:2024-01-26
Resolved:2024-01-26
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.
Integration of JDK-8295166 into 23-b2 has caused a 3% regression in J2dBench-vimg_copyarea-ZGC on Windows x64
Comments
Thanks Robert, closing as not an issue then.
26-01-2024
Since filing this bug with 23+2, performance recovered in b3 & b4. then dropped again in b5. and then recovered yet again in b6. There appears to be modal levels from the benchmark.
Given this, please close as not an issue.
25-01-2024
I have now investigated this a bit more and run some experiments. The only change that may impact performance are the additional calls to print_method. In product builds, print_method only submits JFR events, and according to JDK-8046157 there should be no measurable overhead when JFR tracing is disabled. From the experiment results, it doesn't look like the changes themselves incur any overhead, but it would be great if you could help me interpret the results [~resii]. Based on the experiment results, I suggest we close this as not an issue.
16-01-2024
I think that's a good idea to revisit the JFR events. I'm not sure which phases originally wanted to be tracked. Maybe it's enough to only dump them at certain IGV print levels. But maybe that's also too verbose. Splitting the JFR dumps into a separate product method is also a reasonable idea. Then it can diverge from the print levels of IGV.
20-12-2023
Not including print_method()s in product sounds like a reasonable idea to me (and this is what I first proposed for JDK-8295166). We chose not to do so because we still wanted to post JFR events as part of print_method. [~chagedorn] Maybe this is a good opportunity to revisit this in general, as you've suggested before?
I would suggest that we make print_method non-product only, and that we extract the product part of print_method (that posts a JFR event) into a separate function that we can then use more sparingly.
19-12-2023
ILW = Regression as a side effect when adding supporting debugging code, single benchmark, no workaround = MLH = P4
19-12-2023
[~dlunden] Might be due to calling `print_method()` more often? Maybe we should make sure that this method does nothing in product. Can you have a look at it?