On Wed, 7 Dec 2022 23:10:11 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
>> Test should not check that Eden has decreased in used size if the GCCause is >> "No GC". >> >> These happen with the message "end of concurrent GC pause" which is logged >> by the GCMemoryManager _conc_gc_memory_manager (in G1MonitoringSupport). >> This GCMemoryManager only interacts with the old gen memory pool, so it is >> expected that eden usage does not change. >> >> Updated a few variable names to make it more obvious what count and number >> are recording, and some formatting. The key part of the change is at line >> 137 onwards. > > This bug appears to be a regression caused by the fix for: > > [JDK-8297247](https://bugs.openjdk.org/browse/JDK-8297247) Add > GarbageCollectorMXBean for Remark and Cleanup pause time in G1 > > so I've bumped the priority from P4 -> P2 since it appears to be a > regression. I've > also retargeted the bug from '21' -> '20'. Thanks for the reviews, thanks @dcubed-ojdk for the pointer to the other change - this did not start failing by coincidence, there are new notifications happening. It is hard to reproduce the failure, and they are mostly on linux aarch64, but I've seen one locally on linux x64. The failures show an event where Eden size does not change: the test says that eden before size <= after size is a failure. I cannot reproduce the problem with this change in mach5 or locally, in many runs. Yes, the cleanup changes are distracting, but "count"? That should be more meaningful. 8-) ------------- PR: https://git.openjdk.org/jdk/pull/11572
