RFR(M): 8190828: Test plan: JEP 8171181: Support heap allocation on alternative memory devices
sangheon.kim
sangheon.kim at oracle.com
Fri Nov 17 23:41:16 UTC 2017
Hi Kishor,
On 11/17/2017 02:59 PM, Kharbas, Kishor wrote:
>
> 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:
>
> 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
>
> */[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./*
>
Please keep as is.
I think handling stdout seems okay with @run approach but @run doesn't
allow to add more vm options. In this test, we need 'test_dir', so we
can't use @run.
> *//*
>
>
> 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?/*
>
No need so huge heap. Please refer UseComporessedOops.java for an
example of each cases.
universe.hpp:378 also has good explanation.
e.g. -Xmx32m -XX:HeapBaseMinAddress=0x800000008 also uses non-zero based.
/*
*/
>
> *//*
>
>
> --------------------------------------
> 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.
>
> */[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?/*
>
>
Let's leave as is.
> 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./*
>
OK.
But, if you agree to go 1) option(adding @run, instead of making
TestGCBasherWithAllocateHeapAt.java, this comment can be ignored./*
*/
>
> *//*
>
>
> 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./*
>
Make sense to have longer timeout, not sure additional 300ms is good
enough though.
At least when I ran your 8190308(webrev.15) with this webrev.2, all
tier1~tier5 tests were okay. There were some failures but those are
known issues.
Thanks,
Sangheon
>
> Thanks,
> Sangheon
>
>
>
>
> JEP: https://bugs.openjdk.java.net/browse/JDK-8171181
> <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/20171117/a0da4348/attachment.htm>
More information about the hotspot-gc-dev
mailing list