Number of agent VMs unbounded even when running with -concurrency:N ?

[Jonathan Gibbons]

On 11/22/2013 02:48 AM, Alan Bateman wrote:
>
> Mike Duigou and I were chatting yesterday about the number of VMs that 
> are might be in memory at a time when running in agentvm mode with 
> -concurrency:N. We're not using -compilejdk so I think the starting 
> answer is N+1 (the additional 1 because of jtreg itself). With the jdk 
> tests then it gets complicated because there are some areas when the 
> tests are configured to run in othervm mode, also there are many tests 
> that spin up several VMs for the duration of the test.
>
> One point of discussion is we have different understanding on is what 
> happens when a test is configured to run with a specific set of VM 
> options. So suppose we are running with -concurrency:N and the agent 
> pool has N agents already. If jtreg encounters a test with a 
> completely new set of VM options then does it spin up a new VM (hence 
> growing the pool to N+1) or does it close down one agent VM and spin 
> up a new one?
>
> I skimmed through the jtreg code but it wasn't immediately obvious. 
> Mike went one further and plotted the number of VMs that he sees on 
> his system when running with -concurrency:11. His plots support his 
> understanding that the number of VMs may be unbounded.
>
> -Alan.

I'm sorry I missed this when it was first posted.

I agree that the expected behavior should be N+1 VMs, plus transient 
extra VMs as needed for indidivual tests.

If you have evidence that the set of VMs is growing without bound, I 
would be interested to follow up on that.  I would (obviously) regard 
that as a fairly high priority bug.  I did check the jtreg code, and the 
following lines in MainAction.java reflect the intent that you can only 
use test-specific JVM options in conjunction with /othervm mode:

>         if (!othervm) {
>             if (testJavaArgs.size() > 0)
>                 throw new ParseException(testJavaArgs + 
> MAIN_UNEXPECT_VMOPT);


How easy would it be to run something like jps within a loop while jtreg 
is running, and save the output for analysis, so that we can easily see 
the java commands that were active as the number of VMs increases?

-- Jon