RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs

sangheon.kim at oracle.com sangheon.kim at oracle.com
Sat Jan 19 15:17:18 UTC 2019

Hi Kishor,

Sending to 'hotspot-gc-dev' as well.

On 1/17/19 6:42 PM, Kharbas, Kishor wrote:
> Greetings,
> I ran this test multiple times on Linux & Windows and the tests 
> complete in less than a second. However, I do not have a sparc system 
> to test (if I am correct, earlier discussion pointed that timeout 
> issue is seen on sparc).
> My guess of what is happening is – For testing purposes we use the 
> file system of the test directory, instead of a dax filesystem for 
> nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a 
> temporary file in the test directory. Depending on the test 
> environment (filesystem, memory, disk, etc), heap memory access might 
> be quite slower.
> So I think we should decrease the heap size of the tests. The 5th & 
> 6th subtests can be changed to use 32M instead of 4G. The 4^th subtest 
> can be removed.
> Here is the patch with the changes - 
> http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ 
> <http://cr.openjdk.java.net/%7Ekkharbas/8213695/webrev.00/>
Looks good to me.
And I can sponsor this patch, but we need a review from a (R)eviewer.

FYI, I tested the patch on sparc machines(same kind of machines which 
reported the problem) for 40 times and its run time was mostly less than 
3 seconds.


> Hopefully someone can test whether this change makes the run time 
> deterministic.
> Thanks,
> Kishor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190119/0def4150/attachment.html>

More information about the hotspot-gc-dev mailing list