> On Mar 9, 2018, at 3:42 AM, Claes Redestad <claes.redes...@oracle.com> wrote:
>
> Hi,
>
> the stress test I introduced together with JDK-8196869 to guard against
> introducing NPE issues
> in the Locale cache handling has been shown to fail with OOME on some very
> particular machine
> configurations. Experiments show that we could make such OOMEs easily go away
> by increasing
> the heap size in the test to allow GC to keep up, but then the test will no
> longer reliably
> reproduce the NPE issues the test was designed to guard against.
>
> I think the best we can do is to ignore the OOMEs in this particular stress
> test (which
> runs reliably on almost all of our test systems):
>
> http://cr.openjdk.java.net/~redestad/8199009/jdk.00/
>
> Bugs: https://bugs.openjdk.java.net/browse/JDK-8199009
>
49 } catch (OutOfMemoryError e) {
50 // Can happen on some system configurations, and while
increasing heap
51 // size would allow GC to keep up, it makes it impractically
hard to
52 // reproduce NPE issues that could arise when references are
being
53 // cleared. Do a System.gc() to try to reclaim enough memory
to not
54 // throw an OOME again in the jtreg wrapper.
55 System.gc();
56 }
Since the test is run with main/othervm why bother with System.gc?
Paul.
> Another option would be to remove the test, since it's "only" testing for a
> very particular
> coding error that I was about to commit when working on JDK-8196869..
>
> Thanks!
>
> /Claes
