Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing

Alan Bateman Alan.Bateman at oracle.com
Sat Apr 21 07:42:48 UTC 2012


On 20/04/2012 23:40, Darryl Mocek wrote:
> I've modified the implementation:
>
> - Use LocateRegistry.createRegistry(0) where possible (it's not 
> possible in all places), rather then creating a ServerSocket, getting 
> the port, then closing it and returning the port number.
> - Added a TestLibrary.getRegistryPort(Registry) method to get the port 
> number of the registry.
> - Added java/rmi and sun/rmi back to the list of tests which must be 
> run in othervm mode.
> - Added back othervm to the tests I removed it from.
> - Fixed the AltSecurityManager test and removed it from the ProblemList.
>
> Revised webrev can be found here: 
> http://cr.openjdk.java.net/~dmocek/7142596/webrev.01
As a sanity check I ran the java/rmi and sun/rmi tests on an 8-core 
machine, specifying -concurrency:auto to jtreg.

Without your patch then these tests are forced to run sequentially (by 
the exclusiveAccess.dirs setting) and completed in 28m 11s for me.

I applied your patch and they completed (successfully) in 4m 8s.

So this is good stuff. I think Stuart is going to review the patch in 
detail, I don't think I have time to go through all of it but will try 
to at least scan it. One thing that I want to look for is to check that 
the VM options are passed through to any rmid or rmiregistry processes 
that are created in the tests. This is important when running with 
concurrency>1 to ensure that we don't over-commit memory - for example I 
might run with jtreg -vmoption:-Xmx512m so that agent VMs or processes 
launched by the test harness don't consume 1/4 of the memory and we need 
to ensure these options get propagated through to rmi* processes that 
these tests might launch. This issue wasn't a problem when trying your 
patch because the system I ran on had 24GB (but it could be an issue on 
a lesser machine).

-Alan



More information about the core-libs-dev mailing list