RFR (S): 8006413: Add utility classes for writing better multiprocess tests in jtreg

[Vitaly Davidovich]

Stuart,

You want them daemon here because prior to joining on them, it calls
waitFor() on the process.  If it gets interrupted, the join calls are
skipped.  Now, it may end up that those threads will exit anyway due to
their run loop exiting if process dies and streams return an error or read
-1.  However, instead of relying on that "global context/knowledge" it
seems easier/more robust to just daemonize them.

My $.02

Thanks

Sent from my phone
On Jan 16, 2013 4:52 PM, "Stuart Marks" <stuart.marks at oracle.com> wrote:

> Hi everybody,
>
> I work on the JDK core libraries. It turns out that there is a similar
> library used for testing RMI. Take a look at jdk/test/java/rmi/testlibrary.
> It's been around for quite some time already, but I've been doing some
> maintenance on it recently. (Also, it still needs more work.)
>
> Since the RMI library is in the jdk repo and these test utilities are in
> hotspot, it seems like sharing of code might be difficult. But we might
> want to compare notes. Here are some observations and comments (though not
> an actual code review).
>
> * The use of a pair of threads (StreamPumper) to collect output from the
> subprocess is very similar to what RMI does. See the StreamPipe class in
> RMI's test library, which are used by the JavaVM utility class. One thing I
> did do recently was to make sure that the subprocess is waited for and the
> threads are joined. This hadn't been done before, leading to race
> conditions where some subprocess output was dropped.
>
> * Since these threads are specifically joined, I'm not sure of the utility
> of making them daemon threads.
>
> * My style in writing test code and test library code is to be quite
> verbose about everything and to check every possible error condition.
> Nothing is worse than seeing a test fail and not having enough information
> in the log to find out why. Actually, I can think of something worse:
> having a test pass erroneously because some error condition wasn't checked.
> (Yes, this has happened.)
>
> * Another style point is that I think it's OK for test library code just
> to throw exceptions out to the caller. My test code usually has 'throws
> IOException' or even 'throws Exception' on most of the methods, including
> main, so having test library code throw checked exceptions is reasonable.
> Jtreg will catch exceptions thrown from main and log them. Usually you want
> tests to fail quickly at the point of error. So, I concur with Vitaly's
> concern about ProcessTools handling of IOException and about letting
> interrupts propagate.
>
> * Actually I have a suggestion from Mandy Chung for RMI's StreamPipe
> threads to catch exceptions and report them back to their "parent" JavaVM.
> This is probably a rare occurrence but it does ensure that any errors that
> occur here won't go unnoticed. See JDK-8005827 ( http://bugs.sun.com/**
> bugdatabase/view_bug.do?bug_**id=8005827<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8005827>)
>
> * Regarding jtreg and test library code, it's pretty simple to use. In
> each test that uses the library code, one adds the @library tag to declare
> the library. It's probably a good idea to add an @build tag to build each
> library class that's used in the test. Things usually work in the absence
> of @build tags, because of implicit compilation, but it's kind of fragile.
>
> Anyway, I just wanted to share some notes and ideas.
>
> s'marks
>
>
> On 1/16/13 4:34 AM, Christian Törnqvist wrote:
>
>> Hi everyone,
>>
>> ?
>>
>> This RFE adds a few utility classes to make it a bit easier to write
>> multi-process tests in jtreg, webrev can be found at
>> http://cr.openjdk.java.net/~**brutisso/8006413/webrev.00/<http://cr.openjdk.java.net/~brutisso/8006413/webrev.00/>
>>
>> ?
>>
>> Thanks,
>>
>> Christian
>>
>>