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.
