New java.lang.Thread tests

New java.lang.Thread tests

[Mark Wielaard]

Hi,

I added a couple of tests for java.lang.Thread but all VMs that I tried
have some different errors.

The VMs were gij-3.2 - sadly I managed to erase my 3.3 CVS tree and a
clean checkout doesn't even compile :[ , kaffe 1:1.0.6-7+.cvs20020411
from Debian unstable and Kissme from CVS. All on i686-pc-linux-gnu.

It would be greatly appreciated if people could check the tests because
it is far to easy to make silly mistakes in these multi-threaded setups.

The new tests are:

gnu.testlet.java.lang.Thread.interrupt
gnu.testlet.java.lang.Thread.name
gnu.testlet.java.lang.Thread.daemon
gnu.testlet.java.lang.Thread.priority
gnu.testlet.java.lang.Thread.isAlive
gnu.testlet.java.lang.Thread.getThreadGroup

The results:

gij-3.2 (hangs on isAlive test)

FAIL: gnu.testlet.java.lang.Thread.priority: New Thread can be set to
priority 6 (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: New Thread can be set to
priority 7 (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: New Thread can be set to
priority 8 (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: New Thread can be set to
priority 9 (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: New Thread can be set to
priority 10 (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: uncaught exception at
"Started Thread has at at most MAX_PRIORITY" number 2
6 of 72 tests failed

kaffe 1.06

FAIL: gnu.testlet.java.lang.Thread.interrupt: join with interrupt flag
throws InterruptedException (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: InterruptedException in
join() clears interrupt flag (number 1)
FAIL: gnu.testlet.java.lang.Thread.daemon: Cannot change daemon state on
current Thread (number 1)
FAIL: gnu.testlet.java.lang.Thread.daemon: Daemon status does not change
when set on current Thread (number 1)
FAIL: gnu.testlet.java.lang.Thread.daemon: Newly created thread gets
daemon status of creator (number 1)
FAIL: gnu.testlet.java.lang.Thread.daemon: Cannot change daemon state on
started Thread (number 1)
FAIL: gnu.testlet.java.lang.Thread.priority: uncaught exception at
"Every Thread can be set to priority 10" number 2
FAIL: gnu.testlet.java.lang.Thread.isAlive: Current running thread is
always alive (number 1)
FAIL: gnu.testlet.java.lang.Thread.getThreadGroup (number 2)
9 of 50 tests failed

Kissme CVS (also hangs on isAlive test)

FAIL: gnu.testlet.java.lang.Thread.interrupt: interrupt() makes
isInterrupted() true (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: isInterrupt() doesn't
clear interrupt flag (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: interrupt() makes
interrupted() true (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: wait with interrupt flag
throws InterruptedException (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: InterruptedException in
wait() clears interrupt flag (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: sleep with interrupt flag
throws InterruptedException (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: InterruptedException in
sleep() clears interrupt flag (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: join with interrupt flag
throws InterruptedException (number 1)
FAIL: gnu.testlet.java.lang.Thread.interrupt: InterruptedException in
join() clears interrupt flag (number 1)
FAIL: gnu.testlet.java.lang.Thread.daemon: Cannot change daemon state on
started Thread (number 1)
FAIL: gnu.testlet.java.lang.Thread.getThreadGroup (number 2)
11 of 86 tests failed

Cheers,

Mark

Re: New java.lang.Thread tests

[Patrick Tullmann]

Mark wrote:
> It would be greatly appreciated if people could check the tests because
> it is far to easy to make silly mistakes in these multi-threaded setups.

FYI, there are some tests in the Kaffe distro (look for
test/regression/*Thread*java) that have worked for a while and are
known to work on the JDK.  You might find ideas there.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann@cs.utah.edu
                Your research fills a much needed gap.

Re: New java.lang.Thread tests

[Mark Wielaard]

Hi,

On Sat, 2002-10-05 at 19:48, Mark Wielaard wrote:
> I added a couple of tests for java.lang.Thread but all VMs that I tried
> have some different errors.

I made a couple of changes and added some small corner case tests. The
most important change was that I split the tests for started, running
and stopped Threads which makes the tests more deterministic.

Another was to not hold a synchronized lock on the Thread object that
you are trying to join() with. That solved the Kissme and gij lockup.
But I think that you should be able to join() a Thread that you (or
someone else!) has a lock on. What do you think?

I also got gcj 3.3 CVS finally to compile. It is much improved compared
to 3.2 and passes all 94 tests (except one for which I have a trivial
patch). Yeah! Now the other VMs may try to compete with that :)

Cheers,

Mark

P.S. Yes, I know that the tests could be buggy and that gcj might have
the same bugs. Could very well be because I studied the libgcj source
code (and GNU Classpath source code) before writing the tests. But if
you think so please let the list know so we can interpret the specs to
improve the tests.

Re: New java.lang.Thread tests

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> Another was to not hold a synchronized lock on the Thread object that
Mark> you are trying to join() with. That solved the Kissme and gij lockup.
Mark> But I think that you should be able to join() a Thread that you (or
Mark> someone else!) has a lock on. What do you think?

I agree.

I don't understand why you needed such a lock for gcj.
In Thread.join(long,int) (in natThread.cc), we acquire a mutex 
before waiting on the condition variable.  Both the mutex and the
condition variable are not visible to Java code.

Tom

Re: New java.lang.Thread tests

[Mark Wielaard]

Hi,

On Tue, 2002-10-08 at 22:43, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> Another was to not hold a synchronized lock on the Thread object that
> Mark> you are trying to join() with. That solved the Kissme and gij lockup.
> Mark> But I think that you should be able to join() a Thread that you (or
> Mark> someone else!) has a lock on. What do you think?
> 
> I agree.
> 
> I don't understand why you needed such a lock for gcj.
> In Thread.join(long,int) (in natThread.cc), we acquire a mutex 
> before waiting on the condition variable.  Both the mutex and the
> condition variable are not visible to Java code.

I didn't need it for the join() but I needed it since I wanted to
notify() the Thread object. The join() just happened to be included in
the synchronized block by accident. See the diff between the original
isAlive test and the new one.

cvs diff -r 1.1 gnu/testlet/java/lang/Thread/isAlive.java

With the original code that test will hang with gij after:
PASS: gnu.testlet.java.lang.Thread.isAlive: Running threads are alive (number 1)

Moving the join() outside the synchronized block makes the test work
(and it is a bit cleaner code).
I have not yet analyzed why the original program hangs with gij.
But if people agree that the original code also is legal then I can add
an extra test for that case.
Kaffe has no problem with the original code.

Cheers,

Mark

Re: New java.lang.Thread tests

[Tom Tromey]

Mark> I didn't need it for the join() but I needed it since I wanted
Mark> to notify() the Thread object. The join() just happened to be
Mark> included in the synchronized block by accident. See the diff
Mark> between the original isAlive test and the new one.

Thanks.

Mark> But if people agree that the original code also is legal then I
Mark> can add an extra test for that case.

I don't see a problem with it offhand.

Tom

Re: New java.lang.Thread tests

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> I didn't need it for the join() but I needed it since I wanted
Mark> to notify() the Thread object. The join() just happened to be
Mark> included in the synchronized block by accident.

I debugged gij running this test.  It does definitely hang.

From JLS 2nd Ed, 17.14:

    The notify method should be called for an object only when the
    current thread has already locked the object's lock.  If the wait
    set for the object is not empty, then some arbitrarily chosen
    thread is removed from the wait set and re-enabled for thread
    scheduling.  (Of course, that thread will not be able to proceed
    until the current thread relinquishes the object's lock.)

See the parenthetical statement.  `notify' doesn't unlock the object
when it performs its task.  So I think that we are *required* to hang
for this program, and that instead you've found a kaffe bug.  Do you
agree?

Tom

Re: New java.lang.Thread tests

[Mark Wielaard]

Hi,

On Wed, 2002-10-09 at 03:29, Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:
> 
> Mark> I didn't need it for the join() but I needed it since I wanted
> Mark> to notify() the Thread object. The join() just happened to be
> Mark> included in the synchronized block by accident.
> 
> [...]
>
> See the parenthetical statement.  `notify' doesn't unlock the object
> when it performs its task. 

Yes, that is why it happened. Thanks.

> So I think that we are *required* to hang
> for this program, and that instead you've found a kaffe bug.  Do you
> agree?

But I am not sure that it is a bug in Kaffe to notify the Thread object
during a join(). They probably use the Thread object itself as lock to
guard Thread state changes. It is probably a bug in the program to use a
"public" object as a monitor especially when it is one with such complex
behavior as Thread has.
I won't add an explicit test for this.
Although it would be interesting to test what the Sun JDK does in this
case.

Cheers,

Mark