Code Review Request - Bug #6948101 & 7142596: RMI JPRT tests are failing (original) (raw)

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