RFR (XS) 8220688: [TESTBUG] runtime/NMT/MallocStressTest.java timed out
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Tue May 21 11:51:47 UTC 2019
On 5/20/19 10:25 PM, David Holmes wrote:
> Hi Coleen,
>
> This is fine to push, but some discussion below ...
>
> On 21/05/2019 6:50 am, coleen.phillimore at oracle.com wrote:
>> Summary: reduce number of threads and iterate rather than sleep.
>
> Reducing the load of this test may be reasonable ... though perhaps it
> should be configured based on available CPUs rather than fixed numbers
> (just a thought).
I'm thinking even the minimal configuration can deal with 50 threads,
which is why I chose it. It's not worth doing anything more complicated
here.
>
> But this test rarely times out (and some failures of the test have
> been incorrectly attributed with this bug - the 10 second attach
> timeout is not at all the same issue as timing out after 1h25m!), so
> your testing is unlikely to have encountered the conditions in which
> the timeout actually manifests. The test normally runs in a few
> minutes on linux so the 1h25m timeout is extreme and seems unlikely to
> be due simply to the load the test produces. So I would not be
> surprised if we continue to see occasional timeouts.
I don't know about the attach timeouts which I've seen in lots of
tests. This test uses jcmd to read the NMT info. There are several
tests that do that in the test suite, but this particular test times out
*a lot*. Looking at the test, the load is very high and there's a long
sleep, so a variable attach response will trigger a timeout for this
particular test. That is why I want to reduce the load and eliminate
the long sleep. You can always open a new bug for the attach mechanism
variation, if one doesn't already exist.
Thanks,
Coleen
>
> Further, the huge variation in execution time for this test across
> different platforms e.g. macOS takes 45 minutes!, suggests there may
> be something else at play here.
>
> Thanks,
> David
>
>> Ran test 20x without timeout and faster now. Left /timeout in test
>> because it doesn't hurt.
>>
>> open webrev at
>> http://cr.openjdk.java.net/~coleenp/2019/8220688.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8220688
>>
>> Thanks,
>> Coleen
More information about the hotspot-runtime-dev
mailing list