JDK-8213695 : gc/TestAllocateHeapAtMultiple.java is slow in some configs
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2018-11-09
  • Updated: 2022-06-21
  • Resolved: 2019-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 12 JDK 13
11.0.17-oracleFixed 12 b29Fixed 13Fixed
Related Reports
Relates :  
JDK-8204529 - gc/TestAllocateHeapAtMultiple.java fail with Agent 7 timed out
Description
The following test takes different amounts of time depending
on the testing config:

gc/TestAllocateHeapAtMultiple.java

The default timeout for the test was increased to 360 seconds
via the following bug to reduce the timeout noise in the CI:

    JDK-8204529 gc/TestAllocateHeapAtMultiple.java fail with Agent 7 timed out
Comments
Fix request [11u] I backport this for parity with 11.0.17-oracle. No risk, only a test change. Clean backport. Test passes. SAP nighlty testing passed.
21-06-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1151 Date: 2022-06-15 07:37:27 +0000
15-06-2022
Git URL: https://github.com/openjdk/jdk/commit/755d163e911bae96065298d0abddabf5b0eb3000
15-06-2022
URL: http://hg.openjdk.java.net/jdk/jdk12/rev/5f237f2cd5b2 User: sangheki Date: 2019-01-22 19:43:05 +0000
22-01-2019
I tested total of 40 iterations on large Sparc machines and actual test run time was mostly less than 3 sec. So I think the patch seems okay. [~kkharbas] Could you send RFR?
18-01-2019
Thanks [~kkharbas] for fixing this issue and accepting the proposal. I can sponsor it. I will let you know after some testing.
18-01-2019
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 4th subtest can be removed. Here is the patch with the changes - http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ Hopefully someone can test whether this change makes the run time deterministic.
18-01-2019
So here's what the default timeout was changed to by JDK-8204529: $ hg diff diff -r 35986f2223fe test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java --- a/test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java Fri Nov 02 12:33:28 2018 -0700 +++ b/test/hotspot/jtreg/gc/TestAllocateHeapAtMultiple.java Thu Nov 08 19:45:05 2018 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * @library /test/lib * @modules java.base/jdk.internal.misc * @requires vm.bits == "64" & vm.gc != "Z" & os.family != "aix" + * @run main/timeout=360 TestAllocateHeapAtMultiple */ import jdk.test.lib.JDKToolFinder; The reason for the variance needs to be investigated and hopefully can be fixed (perhaps with additional options) so that the default timeout can be lowered.
09-11-2018