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