RFR(S): 8152989: serviceability/tmtools/jstat/GcCauseTest02.java fails with OOME

Jon Masamitsu jon.masamitsu at oracle.com
Thu Apr 7 17:46:36 UTC 2016

On 04/07/2016 12:18 AM, Per Liden wrote:
> Hi Jon,
> On 2016-04-06 23:47, Jon Masamitsu wrote:
>> Per,
>> On 04/06/2016 02:32 AM, Per Liden wrote:
>>> Summary: This patch updates the tests in serviceability/tmtools/jstat/
>>> to use a fixed (and relatively small) heap size. Without this these
>>> tests tend to run out of memory on machines with VM overcommit
>>> disabled. This has happened in nightly testing.
>> So this fix works because multiple tests running on the same machine
>> does not over reserve memory because a small heap maximum is used?
>> I can see how the fix works but I can see how it could fail on some 
>> machine
>> (maybe small memory machine?) if too many tests are started.  Is there
>> an agent mode JTREG that could be used to run the test in the same JVM?
>> If that could be used I think if JTREG could be run, then the tests 
>> would
>> run.  If JTREG cannot be run, then it's more obviously a setup problem.
> I don't think we're executing more than one test at a time here, but 
> jtreg can start more than one VM to run the test and there might be 
> aurora agents etc running on the machine. We already have quite a few 
> tests using -Xmx128 so it shouldn't be a problem with regards to small 
> machines.

Ok.  That's fine.


> cheers,
> Per
>> Jon
>>> The patch also moves a misplaced @ignore tag and cleans out an unused
>>> method.
>>> Testing: Without this patch I can easily get these tests to OOM on my
>>> local workstation by just disabling VM overcommit. They pass with this
>>> patch applied.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152989
>>> Webrev: http://cr.openjdk.java.net/~pliden/8152989/webrev.0/
>>> cheers,
>>> Per

More information about the hotspot-gc-dev mailing list