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.

Reply via email to