RFR: 8258481: gc.g1.plab.TestPLABPromotion fails on Linux x86

[Kim Barrett]

On Fri, 18 Dec 2020 15:17:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for this test bug fix on x86 (but it did not do the correct thing on 64 bit platforms either)?
> 
> There are sone test cases that allocates byte arrays of ~3500 bytes, and expect that almost all allocations occur in the PLABs given a PLAB waste threshold of some percentage, in this case 20%.
> 
> On x64 this is good, as the PLAB size is 4096 *words*, i.e. 32kb, and 20% of that is ~6.5kb. So all objects are allocated in PLABs as expected
> 
> On x86 the PLAB size of 4096 words is only 16kb, and 20% of that is ~3.2kb. This threshold is less than these 3500 bytes, so the test fails.
> 
> It does not fail always (but very often) because of the broken calculation for meeting the threshold: unless really *all* objects copied are of that 3500 byte size (and hence directly allocated), the current checking using integer calculation results in 0% waste, which is below the expected 20%.
> 
> The suggested fix is to lower the size of that array to 3250 bytes, which meets the criteria on both 32 and 64 bit platforms (and fix the broken calculations).
> 
> Note that we should not change this array size to much lower, because there is another test that fails otherwise.
> 
> Testing:
> 100 successful test runs on x86 and x64 linux each
> 
> Thanks,
>   Thomas

test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java line 225:

> 223:      */
> 224:     private static boolean checkRatio(long checkedValue, long controlValue) {
> 225:         return ((double)Math.abs(checkedValue) / controlValue) * 100L < MEM_DIFFERENCE_PCT;

Rather than casting to double (I'm not fond of casting in Java either), why not
`(Math.abs(checkedValue) * 100.0) / controlValue < MEM_DIFFERENCE_PCT`
Similarly for checkDifferenceRatio below.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1842