United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7144861 RMI activation tests are too slow
JDK-7144861 : RMI activation tests are too slow

Details
Type:
Bug
Submit Date:
2012-02-11
Status:
Closed
Updated Date:
2013-12-17
Project Name:
JDK
Resolved Date:
2012-05-22
Component:
core-libs
OS:
generic
Sub-Component:
java.rmi
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:
Relates:
Relates:
Relates:

Sub Tasks

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
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.
                                     
2012-04-27
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.
                                     
2012-04-27
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.
                                     
2012-04-27
SUGGESTED FIX

Using the first suggested fix above divides the needed running time by a closed to 2 factor.
                                     
2012-04-27
Now, the jdk-rmi takes about 16min on Linux. It is significantly improved
                                     
2013-08-20



Hardware and Software, Engineered to Work Together