Number of agent VMs unbounded even when running with -concurrency:N ?
Alan.Bateman at oracle.com
Fri Nov 22 10:48:16 UTC 2013
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.
More information about the jtreg-use