Integrated: 8292350: Use static methods for hashCode/toString primitives
On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov wrote: > It's a bit shorter and clearer. This pull request has now been integrated. Changeset: 37c0a136 Author:Andrey Turbanov URL: https://git.openjdk.org/jdk/commit/37c0a13647e74fd02823a3f621e986f96904b933 Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod 8292350: Use static methods for hashCode/toString primitives Reviewed-by: prr, rriggs, amenkov, jpai - PR: https://git.openjdk.org/jdk/pull/9816
Integrated: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN"
On Thu, 11 Aug 2022 18:27:12 GMT, Kevin Walls wrote: > This is test unstable when monitoring CodeHeap pools as they can change > outside the test's control. > Attempting more heuristics to sense these unrelated changes just means we > skip more pools. > > The test design, making a Java allocation to affect a memory pool, shows it > was intended for Java heap pools, so the test should focus on them. If we > make a larger allocation during the test we actually can observe a change in > size in the old gen pools it monitors (new gen pools are not expected to have > thresholds, so they are skipped). > > There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx which > are intended for non-heap pools, so we should skip them intentionally here in > isUsageThresholdExceeded. > > Other edits in the test to fix that the peak usage reported by the test was > simply usage, not peak. Fetch the usage and peak usage as near together as > possible in the test. At line 110 in the test, remove an attempt to skip > pools we can't monitor (which was working, but does not cover all cases). > > > Example test log, showing allocation that hits the old gen and triggers the > threshold set by the test: > > --System.out:(15/796)-- > ... > 5 pool G1 Old Gen of type: Heap memory > used value is 1024000 max is 1038090240 isExceeded = false > peak used value is 1024000 > threshold set to 1024001 > threshold count 0 > reset peak usage. peak usage = 1024000 isExceeded = false > Allocated heap. isExceeded = true > used value is 106930176 max is 1038090240 isExceeded = true > peak used value is 106930176 peak max is 1038090240 > threshold count 1 This pull request has now been integrated. Changeset: 3601e30d Author:Kevin Walls URL: https://git.openjdk.org/jdk/commit/3601e30df794db122d8d04fb3c04868ccbaa0baf Stats: 19 lines in 1 file changed: 4 ins; 8 del; 7 mod 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMM and used peak = NNN" Reviewed-by: cjplummer, amenkov - PR: https://git.openjdk.org/jdk/pull/9842
Re: RFR: 8290909: MemoryPoolMBean/isUsageThresholdExceeded tests failed with "isUsageThresholdExceeded() returned false, and is still false, while threshold = MMMMMMM and used peak = NNNNNNN" [v2]
On Fri, 12 Aug 2022 10:05:39 GMT, Kevin Walls wrote: >> This is test unstable when monitoring CodeHeap pools as they can change >> outside the test's control. >> Attempting more heuristics to sense these unrelated changes just means we >> skip more pools. >> >> The test design, making a Java allocation to affect a memory pool, shows it >> was intended for Java heap pools, so the test should focus on them. If we >> make a larger allocation during the test we actually can observe a change in >> size in the old gen pools it monitors (new gen pools are not expected to >> have thresholds, so they are skipped). >> >> There exist specific tests in test/hotspot/jtreg/compiler/codecache/jmx >> which are intended for non-heap pools, so we should skip them intentionally >> here in isUsageThresholdExceeded. >> >> Other edits in the test to fix that the peak usage reported by the test was >> simply usage, not peak. Fetch the usage and peak usage as near together as >> possible in the test. At line 110 in the test, remove an attempt to skip >> pools we can't monitor (which was working, but does not cover all cases). >> >> >> Example test log, showing allocation that hits the old gen and triggers the >> threshold set by the test: >> >> --System.out:(15/796)-- >> ... >> 5 pool G1 Old Gen of type: Heap memory >> used value is 1024000 max is 1038090240 isExceeded = false >> peak used value is 1024000 >> threshold set to 1024001 >> threshold count 0 >> reset peak usage. peak usage = 1024000 isExceeded = false >> Allocated heap. isExceeded = true >> used value is 106930176 max is 1038090240 isExceeded = true >> peak used value is 106930176 peak max is 1038090240 >> threshold count 1 > > Kevin Walls has updated the pull request incrementally with one additional > commit since the last revision: > > Remove fetching and logging of peak max usage. thanks Alex! - PR: https://git.openjdk.org/jdk/pull/9842
Re: RFR: 8282684: Obsolete UseContainerCpuShares and PreferContainerQuotaForCPUCount flags
On Fri, 19 Aug 2022 18:41:12 GMT, Harold Seigel wrote: > Please review this fix to obsolete two container JVM flags related to using > CPU shares to compute active processor count within containers. This fix > obsoletes the flags and removes the use of CPU shares from the calculations. > The fix was tested by running the container tests on Linux x64 and Linux > aarch64 using Mach5 > > Thanks, Harold Looks good. Thanks. - Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.org/jdk/pull/9948
