RFR: 8005290: remove -showversion from RMI test library subprocess mechanism (original) (raw)

Stuart Marks stuart.marks at oracle.com
Thu Dec 20 01:11:14 UTC 2012

Hi all,

Please review the fix [1] for bug 8005290 [2].

[1] http://cr.openjdk.java.net/~smarks/reviews/8005290/webrev.0/

[2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005290

I just filed this bug, so it hasn't made it to the public website yet. The salient text from the bug report is as follows:

The RMI test library (jdk/test/java/rmi/testlibrary) has a convenience API (the JavaVM class) for launching a JVM subprocess. When starting the subprocess, it adds the -showversion option to the JVM command line and waits for the version output to arrive from the subprocess before returning to the caller. This is intended to avoid race conditions where the test might try to contact the subprocess before it's fully initialized.

It turns out this doesn't really work and it's also unnecessary.

The reason it doesn't really work is that the version string is emitted when the JVM subprocess has mostly started up, but it hasn't yet executed any user code. Even after the version string has been emitted, the caller may still have to wait and retry before successfully contacting a service exported by the subprocess. The current code returns after two seconds, even if the version string hasn't been received from the subprocess. So the caller has to wait and potentially retry anyway. Since the callers have to do this anyway, having the library wait for the version string isn't helpful.

Other library code (e.g., RMID) starts the subprocess and waits until a particular RMI service is ready, so the -showversion mechanism is redundant in that case. Finally, many tests start the subprocess and wait until it finishes, so they don't need the -showversion mechanism either.

Finally, the -showversion mechanism adds a lot of complexity, as it has to interpose between the subprocess output stream and the caller, so we're better off just removing it. All RMI tests continue to pass even with this mechanism removed.

This is basically just test cleanup (no library code changes) to clear the way for future test enhancements to improve performance and reliability.

Thanks,

s'marks

More information about the core-libs-dev mailing list