RFR 9: 8086117: java/lang/Runtime/exec/LotsOfOutput.java still fails intermittently with Process consumes memory

Roger Riggs Roger.Riggs at Oracle.com
Thu Jun 11 09:30:15 UTC 2015


Hi,

Yes a reasonable suggestion; I added a note to the bug for next if there 
is one.

Looking at the failing logs the memory usage only increases on the first 
cycle through the
loop.  In the latest case, it increased by just a bit more than 1Mb and 
so triggered the failure.
Since it seems like a one-time growth (and not a continuous one) updated 
test should not
fail.  (emoji for fingers crossed).

Thanks, Roger


On 6/11/15 8:51 AM, Alan Bateman wrote:
>
>
> On 11/06/2015 06:35, David Holmes wrote:
>> On 10/06/2015 11:29 PM, Peter Levart wrote:
>>> Hi Roger,
>>>
>>> I don't know how the tests are executed in your environment, but is it
>>> possible that, while you're running the test in a shared VM, some other
>>> concurrent activity allocates from heap and that the test fails because
>>> of that and not because of Process.exec() at all?
>>
>> I tend to agree - perhaps the test should be run in /othervm mode?
> Sound right although just on Peter's comment, I'm not aware of any 
> jtreg mode that runs tests concurrently in the same VM. The agent VM 
> mode (that I assume most of us use nowadays) executes the tests 
> sequentially in each VM. There is also the possibility of tests 
> leaving looping threads behind or leaking resources and that can cause 
> issues for tests that run subsequently in the same VM. The other thing 
> is that it's possible to have a pool of agent VMs so many tests may be 
> running concurrently in different VMs and this creates another form of 
> potential interference.
>
> -Alan.




More information about the core-libs-dev mailing list