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

Alan Bateman Alan.Bateman at
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 mailing list