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.
Thanks,
Sangheon
> 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.org/pipermail/hotspot-gc-dev/attachments/20190119/0def4150/attachment.htm>
More information about the hotspot-gc-dev
mailing list