On 23/10/2019 17:54, Sergey Bylokhov wrote:
On 10/22/19 6:09 am, Alexey Ivanov wrote:
Then, isn't it is a product bug on windows rather than a test issue?
That it runs for a long time? It's hard to say… The test has always
been slower on Windows.
Then probably we can exclude windows 32bit by the jtreg tag? And
continue to
test other platforms that they work properly and fast.
I'm confused now. Why would we exclude 32-bit Windows? It is the only
platform where the original bug could be reproduced and where OOME or
NPE is thrown in the test. With 64-bit platforms, it's nearly impossible
to exhaust native memory to the state where OOME or NPE is thrown. It's
the reason why the unmodified test takes too long on 64-bit Windows.
But it will be good to check why it is so slow, probably our native code
compiled using wrong flags?
Yeah, probably it makes sense to investigate where the most time is
spent on Windows.
The product bug JDK-8201433 was that it could crash and it did on 32
bit Windows. The test verifies JDK does not crash, it may throw OOME
or NPE.
With this patch I'm trying to reduce the time it takes to run the test.
--
Regards,
Alexey
