On Thu, 8 Dec 2022 19:55:24 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> This fixes two separate CRs: >> >> [JDK-8241293](https://bugs.openjdk.org/browse/JDK-8241293) >> CompressedClassSpaceSizeInJmapHeap.java time out after 8 minutes >> [JDK-8298073](https://bugs.openjdk.org/browse/JDK-8298073) >> gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java causes test task >> timeout on macosx >> >> For the first one the test was hitting an 8m timeout, but completing right >> after that. The test log said PASSED, but jtreg failed it anyway because it >> noticed the timeout. The fix is to double the default 120s timeout to 240s >> (which is 16m when the 4x timeoutfactor is applied. >> >> For the second one the issue seemed to be with having the test process spawn >> a jhsdb process that attached back to the test process. OSX didn't seem to >> be too happy about this. The fix is to instead create a LingeredApp process >> to attach to like all the other SA tests do. > > Chris Plummer has updated the pull request incrementally with one additional > commit since the last revision: > > Update > test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java > > Delete extra space. > > Co-authored-by: Andrey Turbanov <turban...@gmail.com> test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 35: > 33: * @modules java.base/jdk.internal.misc > 34: * java.management > 35: * @run main/timeout=240 gc.metaspace.CompressedClassSpaceSizeInJmapHeap Suggestion: * @run main/timeout=240 gc.metaspace.CompressedClassSpaceSizeInJmapHeap ------------- PR: https://git.openjdk.org/jdk/pull/11576
