Review Request for CR : 7144861 RMI activation tests are too slow

[Olivier Lagneau]

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.