JDK-7144861 : RMI activation tests are too slow
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-02-11
  • Updated: 2018-04-25
  • Resolved: 2012-05-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u21Fixed 8 b40Fixed
Related Reports
Relates :  
JDK-8201469 - test under java/rmi should be restricted to not run concurrently
Relates :  
JDK-8005436 - TEST_BUG: speed up RMI tests
Relates :  
JDK-8005290 - TEST_BUG: remove -showversion from RMI test library subprocess mechanism
Relates :  
JDK-7168267 - TEST_BUG: Cleanup of rmi regression tests (activation and others)
Description
The RMI regression tests, particularly the activiation tests, are just too slow to be usable.

The jdk_rmi batch typically takes 30-40 minutes in JPRT.

The following shows the tests for the activation tests on a typical system, the number at the end is the duration of the test in ms. These tests cannot run concurrently so the accumulative time for any test run that includes the RMI tests is huge (on a 8 core system they it the RMI tests take 3 times longer than all of the core libs, networking and security tests combined).

JTwork/java/rmi/activation/ActivationSystem/stubClassesPermitted/StubClassesPermitted.jtr:158744
JTwork/java/rmi/activation/CommandEnvironment/NullOptions.jtr:159070
JTwork/java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.jtr:164341
JTwork/java/rmi/activation/ActivationGroupDesc/checkDefaultGroupName/CheckDefaultGroupName.jtr:173895
JTwork/java/rmi/activation/ActivationSystem/modifyDescriptor/ModifyDescriptor.jtr:176709
JTwork/java/rmi/activation/checkusage/CheckUsage.jtr:181178
JTwork/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.jtr:190214
JTwork/java/rmi/activation/Activatable/unregisterInactive/UnregisterInactive.jtr:190970
JTwork/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.jtr:191248
JTwork/java/rmi/activation/ActivationGroup/downloadActivationGroup/DownloadActivationGroup.jtr:194025
JTwork/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.jtr:194093
JTwork/java/rmi/activation/Activatable/restartService/RestartService.jtr:197906
JTwork/java/rmi/activation/Activatable/checkAnnotations/CheckAnnotations.jtr:202901
JTwork/java/rmi/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.jtr:205142
JTwork/java/rmi/activation/rmidViaInheritedChannel/RmidViaInheritedChannel.jtr:214983
JTwork/java/rmi/activation/rmidViaInheritedChannel/InheritedChannelNotServerSocket.jtr:233020
JTwork/java/rmi/activation/log/LogTest.jtr:233141
JTwork/java/rmi/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.jtr:233701
JTwork/java/rmi/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.jtr:251705
JTwork/java/rmi/activation/CommandEnvironment/SetChildEnv.jtr:251901
JTwork/java/rmi/activation/Activatable/extLoadedImpl/ext.jtr:257564
JTwork/java/rmi/activation/Activatable/elucidateNoSuchMethod/ElucidateNoSuchMethod.jtr:260621
JTwork/java/rmi/activation/Activatable/notSerializable/NotSerializable.jtr:261221
JTwork/java/rmi/activation/Activatable/restartLatecomer/RestartLatecomer.jtr:271866
JTwork/java/rmi/activation/Activatable/lookupActivationSystem/LookupActivationSystem.jtr:279209
JTwork/java/rmi/activation/Activatable/nonExistentActivatable/NonExistentActivatable.jtr:279288
JTwork/java/rmi/activation/Activatable/nestedActivate/NestedActivate.jtr:279293
JTwork/java/rmi/activation/Activatable/downloadParameterClass/DownloadParameterClass.jtr:280818
JTwork/java/rmi/activation/Activatable/restartCrashedService/RestartCrashedService.jtr:290207
JTwork/java/rmi/activation/Activatable/inactiveGroup/InactiveGroup.jtr:302325
JTwork/java/rmi/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.jtr:305356
JTwork/java/rmi/activation/Activatable/checkActivateRef/CheckActivateRef.jtr:413016
Comments
Now, the jdk-rmi takes about 16min on Linux. It is significantly improved
20-08-2013
SUGGESTED FIX Using the first suggested fix above divides the needed running time by a closed to 2 factor.
27-04-2012
SUGGESTED FIX There are two other additional improvements that can be applied : - the jtreg build/compile sequences consumes a lot of time when the source code of the test uses several lines with jtreg @build tag. In almost all the test only one such @build line is really needed. Doing this can reduce the time from 8 secs to 2.5 secs ! - Also some of the tests use the same kind of very long sleep() calls. Some of them are useless. For others, applying the same principle as above for testlibrary classes will produce the same time reductions from seconds to tenth of seconds. These two potential additional improvement may be applied in a further improvement stage.
27-04-2012
EVALUATION java rmi activation tests (and a few others) use the the java/rmi/testlibrary classes to manage different things in the case of an rmi regression test: - starting a distant JavaVM that would start a registry or rmid (JavaVM class) - checking the status of distant activatables inside an rmid, availability of rmid, and other such things ...(activationLibrary) - starting up and shutting down an activation daemon (RMID class) - redirecting the standard output and error stream of a child distant vm to streams of the parent vm (StreamPipe) Since there are several vm processes running at the same time in the rmi activation test, waiting for a minimal time to get everything available and responsive in the distant child vm process is needed. Thus many of the methods in the above classes include such waiting times which have been hardcoded to a maximum bound considered to be effective for (hopefully) all test run cases. These waiting times are either implemented as 1 long thread.sleep() call or by loops of a few shorter sleep. However these "safe maximal waiting times" are sometimes very long (JavaVM startup, RMID Startup/availability, RMID shutdown, activatable deactivation ...), much longer than the real time needed to get those actions done. Most of the time consumed by the rmi activation regression tests is due to these long harcoded sleep calls (usually > 20s). Being able to reduce these waiting is key for having activation test running faster.
27-04-2012
SUGGESTED FIX In order to reduce the waiting times, one can generalize usage of waiting loops with small inner waiting times, repeating the sleep calls as many times as an expected check condition is verified, still keeping the "safe" global time thats is currewntly hardcoded in the test. - For example, rather than waiting blindly for 2 secs that distant JavaVM is started, one can try to wait by time slices 100msecs, checking that distant vm is started after each such short waits, bounding the number of such steps to 20 (20 x 100msecs = 2secs). This principle can be used and implemented for almost each long rmi operation.
27-04-2012