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

[sangheon.kim]

Hi Kishor,

On 11/13/2017 03:51 PM, Kharbas, Kishor wrote:
>
> Hi!
>
> 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 
> <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.

--------------------------------------
test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java

   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

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.

--------------------------------------
test/hotspot/jtreg/gc/stress/gcbasher/TestGCBasherWithAllocateHeapAt.java

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.

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?

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.

Thanks,
Sangheon



> 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!
>
> Kishor
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20171116/e1b1813f/attachment.htm>