RFR(M): 8190828: Test plan: JEP 8171181: Support heap allocation on alternative memory devices

Kharbas, Kishor kishor.kharbas at intel.com
Fri Nov 17 22:59:06 UTC 2017

Hi Sangheon!
Thanks for the reply. Please find my reply inline.

From: sangheon.kim [mailto:sangheon.kim at oracle.com]
Sent: Thursday, November 16, 2017 10:28 PM
To: Kharbas, Kishor <kishor.kharbas at intel.com>; hotspot-gc-dev at openjdk.java.net
Subject: Re: RFR(M): 8190828: Test plan: JEP 8171181: Support heap allocation on alternative memory devices

Hi Kishor,
On 11/13/2017 03:51 PM, Kharbas, Kishor wrote:

I have developed a test plan for the implementation of 8171181.
I would appreciate a review and further guidance from the gc-dev members. I am hoping to get everything done well before 18.3 code freeze (have a vacation planned during that time).

Test plan: https://bugs.openjdk.java.net/browse/JDK-8190828
Test webrev: http://cr.openjdk.java.net/~kkharbas/8190980/webrev.01/<http://cr.openjdk.java.net/%7Ekkharbas/8190980/webrev.01/>
Looking at the comment at 8190980, webrev.2 seems the latest one, so my comments are for the webrev.2.


  51     String[] extraOptsList = new String[] {
  52       "-Xmx32m -Xms32m -XX:+UseCompressedOops",     // 1. With compressedoops enabled.
  53       "-Xmx32m -Xms32m -XX:-UseCompressedOops",     // 2. With compressedoops disabled.
  54       "-Xmx32m -Xms32m -XX:HeapBaseMinAddress=3g",  // 3. With user specified HeapBaseMinAddress.
  55       "-Xmx4g -Xms4g",                              // 4. With larger heap size (UnscaledNarrowOop not possible).
  56       "-Xmx4g -Xms4g -XX:+UseLargePages",           // 5. Set UseLargePages.
  57       "-Xmx4g -Xms4g -XX:+UseNUMA"                  // 6. Set UseNUMA.
  58     };
- I think we do differently to run sub-tests. Maybe SQE folks would give better comment on this.
e.g. TestAllocationInEden.java
 * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions
 *                   TestAllocationInEden 10m 9 EDEN
 * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions
 *                   TestAllocationInEden 10m 47 EDEN
 * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions

[Kharbas, Kishor] In my tests I use stdout to check for log generated by -Xlog:heap+gc=info to test correct allocation of Heap. That's why I need to spawn a process from within this test to get a handle on stdout, which (as per my limited knowledge) is not possible if I use @run. Please correct me if I am wrong.

52       "-Xmx32m -Xms32m -XX:+UseCompressedOops",     // 1. With compressedoops enabled.
54       "-Xmx32m -Xms32m -XX:HeapBaseMinAddress=3g",  // 3. With user specified HeapBaseMinAddress.
55       "-Xmx4g -Xms4g",                              // 4. With larger heap size (UnscaledNarrowOop not possible).
- I think these 3 sub-tests are testing different compressed oop modes. I would recommend to include other 1 type(non-zero based) as well. In addition, adding the comment also would help increase the readability.

[Kharbas, Kishor] Yes I can do that. I need to specify heap size close to 32 GB right? There should be that much disk space available in the test environment, do you think that would be problem?


1) This seems identical to TestGCBasherWithG1.java, how about just adding another '@run'?
i.e.  adding "* @run main/othervm/timeout=500 -Xlog:gc*=info -Xmx256m -server -XX:+UseG1GC  -XX:AllocateHeapAt=. TestGCBasherWithG1 120000"

2) Don't we need testing for other GC types as well? i.e. Serial, Parallel and CMS.

[Kharbas, Kishor] The idea was to exercise the Java heap (allocated on a file) by some stress test. I thought one GC option would suffice, do you think we need more?

2  * Copyright (c) 2016, 2017, Oracle and/or its affiliates. All rights reserved.
- Is this intended to start from 2016 as this seems to be copied from TestGCBasherWithXXX.java?

[Kharbas, Kishor] I will change this.

34  * @run main/othervm/timeout=500 -Xlog:gc*=info -Xmx256m -server -XX:+UseG1GC -XX:AllocateHeapAt=. TestGCBasherWithAllocateHeapAt 120000
- Are there any reason to use timeout of 500? TestGCBasherWithG1 is using 200ms.
[Kharbas, Kishor] I increased the timeout since heap is mapped to a file on disk (either HDD or SSD depending on test environment) which makes the test run slower.


JEP: https://bugs.openjdk.java.net/browse/JDK-8171181
Implementation webrev : http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15/<http://cr.openjdk.java.net/%7Ekkharbas/8190308/webrev.15/>

Thank you!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20171117/37db5f72/attachment.htm>

More information about the hotspot-gc-dev mailing list