Please review this fix for making the jdk regression tests for rmi
activation run faster.
It brings a near to x2 speed factor on a Solaris/SPARC machine.
The webrev for the fix is here:
http://cr.openjdk.java.net/~olagneau/7144861/webrev.00/
This is a speedup only fix that does not attempt to cleanup the
rmi/testlibrary code and minimizes the changes.
The fix consists in applying what is described as suggestedFix(Entry 1)
in bug page(see http://monaco.sfbay.sun.com/detail.jsf?cr=7144861).
It mainly reduces long (seconds) waiting times steps by several much
shorter ones (second tenthes) that have been chosen to minimize
and keep usefull the waiting loops. These waiting time values are
hardcoded, as were before the fix.
The additional possible fixes described in suggestFix/Entry2 (grouping
jtreg @build tags, and reducing waiting time in tests) are *not* applied
here.
Below is the detailed list of changes.
Thanks,
Olivier.
Here are the details of the changes I did:
---------------------------------------------b.
- testlibrary/JavaVM.java : rather than waiting once for an "hopefully
sufficient" time of 2secs at the end of
start() method, a way to know when the vm is really started has been
added with the help of redirected buffers
in StreamPipe : in StreamPipe.run(), as soon as we have something to
read in the vm output buffer, it means the
distant vm can be considered started, and thus a synchronized
JavaVM.started() method that sets-up a javaVM "started"
status is called.
We force such an output in the default case (most used one) by
prepending "-showversion" flag in the command line
running distant vm process. At the end of JavaVM.start(), we loop and
wait by steps of 100msecs to check for
the "started" status until the started status is set or max bound
time is reached (keeping the initial max of
2secs bound). If bound is reached without seeing started flag set, vm
is consiedered started anyway.
We keep the previously existing way of starting the vm and using
streamPipe for the cases where we don't want
child vm to output anything or if we don't have any control of child
process (when started without using JavaVM
constructor/start).
In a usual jtreg env, 3 loops are most often enough (300msecs), with
a max of 700msecs seen from numerous trials.
- testlibrary/StreamPipe : this is all described here above.
- testlibray/RMID :
start() method: the existing waiting time slices have been reduced
to 100msecs, before calling rmidRunning().
These were/are useless since rmidRunning() also does such waiting
loops, but the intention is not to cleanup
testlibrary code to avoid confusion and mixing things. So just
reduced the waiting time slices.
Most of the times 1 such waiting step is enough, since rmidRunning
does the same kind of loops.
So we most often see rmid running after 300msecs most often, with
an observed max of 1.1sec.
shutdown() : suppressed useless sleep(5000) which is better handled
in destroy() method. Provide additional
status on communication status with distant rmid.
destroy() : Added a waiting loop on process.exitvalue() (by steps of
200msecs) to have more chances to see distant rmid
process terminates gracefully, while being faster. The max waiting
time bound here is 60secs (300 steps).
Observed needed time varies between 600msecs and 3secs.
- testlibrary/ActivationLibrary :
deactivate(): Waiting time steps reduced from 1000msecs to 100,
enlarging the number of steps to 50 (kept
total waiitng time of 5secs). In almost all cases 1 waiting step is
enough, sometimes up to 5, and only for
CheckImplClassLoader we occasionnally never see inactive call
succeeding.
rmidRunning() : Reduced the waiting time slice to 100msecs and
added some communication/exception status info.
Kept the max waiting time bound of 7.5secs. In most cases 300msecs
(3 steps) is enough.
- CheckUsage test:
main() : suppressed useless sleep of 7secs.
- NoConsoleOutput test:
main() : the only observed test to expect no output from distant vm.
Thus using previously existing method for
instantiating/starting distant vm, with a fixed waiting time of 2secs.
-----------------------------------------------------------e.
