A Concurrent Affair » Concurrent Unit Testing

Java 7 for DrJava and Concutest

Mathias — Mon, 01 Aug 2011 15:58:49 +0000

I worked on Java 7 support this weekend, and I’m almost done. I just discovered that Concutest is currently incompatible with Java 7, though, so I will need to disable the ConcJUnit option in DrJava when using Java 7. I also need to test on Mac and Linux.

I’ll try to finish this tonight so we can get a beta out. Or should we release a stable version without this code?

Fixing Concutest will take a bit longer, of course.

Paging Stuff Back Into My Brain

Mathias — Wed, 20 Oct 2010 22:06:57 +0000

I gave the second lecture as Corky’s substitute in COMP 311 today. We talked about object-oriented languages in general, and Java in particular.

I didn’t talk about the historical perspective on OO (slide 5), and I only mentioned multiple inheritance and prototype-based OO languages briefly. Other than that, I finished slides 1-7, i.e. including “Java Implementation I”. I also talked a bit about static and dynamic chains, how Java doesn’t have a static chain, and why.

I’m always happy when I get the opportunity to do a lecture.

Now I’m loading stuff back into my brain that I had paged out into swap space a few months ago…

No Nifty Assignment for the Educators Symposium

Mathias — Tue, 29 Jun 2010 22:02:48 +0000

I started writing too late and I discovered I still have some strange source of nondeterminism in my supposedly deterministic single-threaded application, so I won’t be submitting a Nifty Assignment to the Educators Symposium at OOPSLA/SPLASH this year.

Too bad. But maybe I’ll have enough together for the next SIGCSE. Paper submissions are due September 10, 2010.

Beethoven and Brainstorming

Mathias — Sun, 16 May 2010 19:28:57 +0000

I went on a walk today, on the prettiest day so far, for some Beethoven and brainstorming. I think I came up with some more nice ties back to my Master’s thesis.

Brainstorming outside.

Sitting outside on a sunny day, with Beethoven in my ears.

Short Summary

Mathias — Tue, 06 Apr 2010 05:58:56 +0000

The last few days summed up:

Happy Easter!
Still working on propagating reachability-from information into the methods. That should allow me to do a simple run-once-run-many analysis.
I noticed my scanner was broken too, not just the power supply.
FedEx delivered my new scanner, a Canon CanoScan LiDE100, on Saturday, and it rocks.
I returned the power supply to RadioShack. Thanks for the loan. I love America.
Congratulations to a very nice MS defense, Jun.

Soot May-Happen-in-Parallel Analysis

Mathias — Thu, 01 Apr 2010 23:49:18 +0000

I got Soot’s “may happen in parallel” (MHP) analysis to work, but only on a very small, completely unrealistic example which I used to test my “shared volatile” code (source below). Even for this, I needed to set the heap size to 2 GB (which, if I remember correctly, won’t work on Windows machines). Anything a little bit bigger either exhausted memory or caused the JVM garbage collector crash.

They must be horribly inefficient with their static analysis. In one of the theses I read today, the biggest benchmarks had 3,800 lines of code. Maybe I am doing something wrong, because they used 1.5 GB heap, but as of now I have doubts their analysis scales to real applications like DrJava.

Furthermore, Soot’s MHP analysis doesn’t take the event thread into account, but this is probably a smaller issue.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77

package testers.volatileVarsThread;

public class VolatileVarsThread {
public static volatile int vsField;
public static int sField;
public static volatile int vsField_notShared;
public static int sField_notShared;

public static void main(String[] args) {
doStuff();
try {
new Thread(new Runnable() {
public void run() {
++vsField;
++sField;

System.out.println("Foo");
int i = doStuff() + doStuff();
System.out.println("i = "+i);

I c = new C();
c.doSomething();
}
}).start();
}
catch(java.lang.Exception e) { }
++vsField_notShared ;
++sField_notShared;
B b = new B();
b.doSomething();
}

public static int doStuff() {
return new A().foo() + 2;
}
}

class A {
public int foo() {
return bar() + 1;
}

public int bar() {
return 123;
}
}

interface I {
public void doSomething();
}

class B implements I {
public volatile int vField_notShared;
public int field_notShared;
public volatile int vField_notSharedButDynamicTarget;
public int field_notSharedButDynamicTarget;
public B() {
++vField_notShared;
++field_notShared;
}
public void doSomething() {
++vField_notSharedButDynamicTarget;
++field_notSharedButDynamicTarget;
System.out.println("B.doSomething");
}
}

class C implements I {
public volatile int vField = 3;
public int field = 4;

public void doSomething() {
vField = 0;
field = 0;
System.out.println("C.doSomething");
}
}

Back and Wanting More

Mathias — Thu, 18 Mar 2010 18:41:21 +0000

This is my second day back from my talks at SIGCSE and Purdue, and I’m already wanting more. We’re finalizing our Mint paper for PLDI, and I’m thinking about a nifty assignment for the SPLASH/OOPSLA Educators’ Symposium.

I couldn’t really find a lot of information about the Educators’ Symposium on the SPLASH/OOPSLA website, except that Educators’ Symposium submissions are supposedly due next week, on March 25.

Fortunately, symposium chair Ed Gehringer told me the Call for Participation will be released within the next two weeks, and that there will be 2.5 to 3 months after that to the submission deadline. Maybe it will coincide with the June 24 deadline for SPLASH posters, demonstrations, submissions to the Doctoral Symposium, Onward! films, and Student Volunteers.

Short, Non-Technical Talks Are Hard

Mathias — Fri, 26 Feb 2010 00:43:20 +0000

I just gave my talk Testing Concurrent Programs, A 7-Minute Jargon-Free Introduction to the students of the Thesis Writing Seminar of the School of Engineering here at Rice. It went very well, but I’ve got to say that this was probably the most difficult talk I’ve had to prepare.

It is a 7-minute talk to an audience of smart engineering graduate students who generally are in all kinds of different fields. You can’t really use jargon or assume too much background knowledge and be too technical, otherwise you might lose your audience. You also can’t spend too much time explaining concepts. And at eight minutes, you get cut off.

I’ve really had to cut the number of slides down, gloss over a few things, and unfortunately also ignore some achievements that I think are really cool, like the reachability check of the join graph, which prevents “lucky” threads. Because of the extremely short time, practicing the talk pays off a lot, because your explanations just have to work. You don’t have time to start over.

The talk went very well and received unanimously positive feedback. What people liked the most was that it was virtually jargon-free, that the animations were simple and helpful, and that I was able to simplify the concepts and make them accessible to non-computer scientists without talking down to them.

Again, I finished working on the presentation only an hour before the talk, and my delivery definitely could have benefited from more time to practice. I also still haven’t figured out how to take a sip of water while giving a talk, but seven minutes fortunately were not long enough to develop a serious case of dry mouth.

Interestingly, Rui Zhang’s talk about software transactional memory was next, and my talk served as a good introduction.

in The Thread of First Use

Mathias — Wed, 17 Feb 2010 05:21:16 +0000

Question: In which thread does run?

Answer: is being executed in whatever thread uses the class first.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

package testers;

import java.awt.EventQueue;

public class CLInit {
public static void main(String[] args) throws Exception {
new CLInit2().doSomething();
EventQueue.invokeAndWait(new Runnable() {
public void run() {
new CLInit2().doSomething();
new CLInit3().doSomething();
}
});
new CLInit3().doSomething();
}
}

class CLInit2 {
static {
System.out.println("CLInit2.: "+Thread.currentThread());
}

public void doSomething() {
System.out.println("CLInit2.doSomething");
}
}

class CLInit3 {
static {
System.out.println("CLInit3.: "+Thread.currentThread());
}

public void doSomething() {
System.out.println("CLInit3.doSomething");
}
}

produces the output

$ java testers.CLInit
CLInit2.: Thread[main,5,main]
CLInit2.doSomething
CLInit2.doSomething
CLInit3.: Thread[AWT-EventQueue-0,6,main]
CLInit3.doSomething
CLInit3.doSomething

As you can see, the class initializer for CLInit2 is run in the main thread, but the one for CLInit3 is executed in the event thread.

The implication of this is that class initializers may run in the event thread (or auxiliary threads) and therefore have to be considered when I compute the methods that are reachable in auxiliary threads or the event thread.

in Which Thread?

Mathias — Tue, 16 Feb 2010 06:58:11 +0000

Question: In which thread does run?

Answer tomorrow.

The Free Java Book

Mathias — Mon, 15 Feb 2010 18:32:05 +0000

Corky just informed me that there is a talk by Daniel L. Schuster at SIGCSE 2010 about Java, games, and the Free Java Book. I’ll definitely check out the talk and the book. I’ll also examine how concurrency is handled in the ACM Java Library.

Daniel is kind enough to state the following in his book:

Dr. Java is the preferred development environment for the Free Java Book. It is an easy to use but powerful editor and development environment. It is available via download and is free. Free as in $0.00! It is available for Windows and Mac.

Thanks! I added a link to the Free Java Book to the list of DrJava user sites.

Java Bug 4396719 Work-Around?

Mathias — Sun, 31 Jan 2010 17:00:54 +0000

It seems like I can get around the garbage collector bug if I use -XX:+UseConcMarkSweepGC JVM argument.

Now I’m having more Soot problems, but they actually make sense. In addition to being cross-platform, DrJava is also “cross-JDK version”: We support JDK versions 5 and 6 and OpenJDK version 6. In the past, we also supported JDK version 4 and various versions of JSR-14 (adding generics to Java 4).

The adapter to the JDK 5 compiler is compiled with and linked against JDK 5; the adapter to the JDK 6 compiler is compiled with and linked against JDK 6. At runtime, we will never use a JDK 5 adapter with a JDK 6 compiler, and vice versa. But when I’m generating the call graph with JDK 6, Soot is now also looking at the JDK 5 adapter.

The JDK 5 com.sun.tools.javac.util.Log class had a String getText(String a, Object[] b) method, but that has disappeared in JDK 6. Therefore, Soot is not finding a method it expects.

I guess I will have to remove the cross-version capability for the purpose of the call graph creation.

Update

On Windows and Mac, using -XX:+UseConcMarkSweepGC actually seems to help. On Linux, I’m still getting a segfault.

Soot Build Instructions

Mathias — Sun, 31 Jan 2010 00:39:42 +0000

While trying to create a call graph of DrJava using Soot, I ran into some problems that were supposed to have been fixed in the Soot nightly builds already. Unfortunately, the nightly builds I could find were all many months old. So I built Soot from scratch from the Subversion repository, which wasn’t an easy task.

Here are some instructions for building Soot:

Make sure you have Ant ant the JDK (5 or newer) installed.
Check out and download all of these code bases in the same directory.
Download Polyglot from http://www.sable.mcgill.ca/soot/soot_download.html:
```
wget http://www.sable.mcgill.ca/software/polyglotclasses-1.3.5.jar
```

Check out Soot from https://svn.sable.mcgill.ca/soot/soot/trunk:

svn checkout https://svn.sable.mcgill.ca/soot/soot/trunk soot-dev

Check out Jasmin from https://svn.sable.mcgill.ca/soot/jasmin/trunk:

svn checkout https://svn.sable.mcgill.ca/soot/jasmin/trunk jasmin-dev

Check out JastAddJ from http://svn.jastadd.org/projects/trunk/JastAddJ:
```
svn co http://svn.jastadd.org/projects/trunk/JastAddJ
```
Check out JastAddExtensions from http://svn.jastadd.org/projects/trunk/JastAddExtensions:
```
svn co http://svn.jastadd.org/projects/trunk/JastAddExtensions
```

You should now have the following directory structure:

.
|-- polyglotclasses-1.3.5.jar
|-- JastAddExtensions
|   |-- ...
|   |-- SootJastAddJ
|   `-- ...
|-- JastAddJ
|   `-- ...
|-- jasmin-dev
|   |-- ...
|   |-- lib
|   |   `...
|   |-- ant.settings.template
|   |-- build.xml
|   `-- ...
`-- soot-dev
    |-- ...
    |-- lib
    |   `...
    |-- ant.settings.template
    |-- build.xml
    `-- ...

Copy jasmin-dev/ant.settings.template to jasmin-dev/ant.settings:
```
cp jasmin-dev/ant.settings.template jasmin-dev/ant.settings
```

Edit jasmin-dev/ant.settings so it contains the following lines:

java_cup.jar=../polyglotclasses-1.3.5.jar
jasmin.version=trunk

Change into the jasmin-dev directory, build the jasminclasses-trunk.jar file, and change back out of the directory:
```
cd jasmin-dev
ant jasmin-jar
cd ..
```
The freshly built Jasmin jar file is jasmin-dev/lib/jasminclasses-trunk.jar.
Change into the JastAddExtensions/SootJastAddJ directory, regenerate the JastAdd-generated files for Soot, and change back out of the directory:
```
cd JastAddExtensions/SootJastAddJ
ant gen
cd ../..
```
Copy soot-dev/ant.settings.template to soot-dev/ant.settings:
```
cp soot-dev/ant.settings.template soot-dev/ant.settings
```

Edit soot-dev/ant.settings so it contains the following lines:

jastaddfrontend.loc=../JastAddExtensions/SootJastAddJ
polyglot.jar=../polyglotclasses-1.3.5.jar
jasmin.jar=../jasmin-dev/lib/jasminclasses-trunk.jar

Change into the soot-dev directory and build the sootclasses-trunk.jar file, and change back out of the directory:
```
cd soot-dev
ant classesjar
cd ..
```
Note: I received a compiler error here. I had to insert the second cast into soot-dev/src/soot/jbco/bafTransformations/FindDuplicateSequences.java to make line 282
1
Unit jump = (Unit) units.getSuccOf(next.get(next.size() - 1));

1	Unit jump = (Unit) units.getSuccOf((Unit)(next.get(next.size() - 1)));

The freshly built Soot jar file is soot-dev/lib/sootclasses-trunk.jar.

Have fun with fresh Soot.

Here’s a bash script that does it all (except insert the cast): build-soot.sh.zip

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

#!/bin/bash

# Make sure you have Ant ant the JDK (5 or newer) installed.
# Check out and download all of these code bases in the same directory.
# Download Polyglot from http://www.sable.mcgill.ca/soot/soot_download.html:
wget http://www.sable.mcgill.ca/software/polyglotclasses-1.3.5.jar

# Check out Soot from https://svn.sable.mcgill.ca/soot/soot/trunk:
svn checkout https://svn.sable.mcgill.ca/soot/soot/trunk soot-dev

# Check out Jasmin from https://svn.sable.mcgill.ca/soot/jasmin/trunk:
svn checkout https://svn.sable.mcgill.ca/soot/jasmin/trunk jasmin-dev

# Check out JastAddJ from http://svn.jastadd.org/projects/trunk/JastAddJ:
svn co http://svn.jastadd.org/projects/trunk/JastAddJ

# Check out JastAddExtensions from
# http://svn.jastadd.org/projects/trunk/JastAddExtensions:
svn co http://svn.jastadd.org/projects/trunk/JastAddExtensions

# Copy jasmin-dev/ant.settings.template to jasmin-dev/ant.settings:
# Edit jasmin-dev/ant.settings so it contains the following lines:
# java_cup.jar=../polyglotclasses-1.3.5.jar
# jasmin.version=trunk
cat jasmin-dev/ant.settings.template | sed \
-e "s/.*$java_cup.jar=$.*/\1..\/polyglotclasses-1.3.5.jar/" \
-e "s/.*$jasmin.version=$.*/\1trunk/" \
> jasmin-dev/ant.settings

# Change into the jasmin-dev directory, build the
# jasminclasses-trunk.jar file, and change back out of the directory:
cd jasmin-dev
ant jasmin-jar
cd ..

# The freshly built Jasmin jar file is
# jasmin-dev/lib/jasminclasses-trunk.jar. Change into the
# JastAddExtensions/SootJastAddJ directory, regenerate the
# JastAdd-generated files for Soot, and change back out of the
# directory:
cd JastAddExtensions/SootJastAddJ
ant gen
cd ../..

# Copy soot-dev/ant.settings.template to soot-dev/ant.settings:
# Edit soot-dev/ant.settings so it contains the following lines:
# jastaddfrontend.loc=../JastAddExtensions/SootJastAddJ
# polyglot.jar=../polyglotclasses-1.3.5.jar
# jasmin.jar=../jasmin-dev/lib/jasminclasses-trunk.jar
cat soot-dev/ant.settings.template | sed \
-e "s/.*$jastaddfrontend.loc=$.*/\1..\/JastAddExtensions\/SootJastAddJ/" \
-e "s/.*$polyglot.jar=$.*/\1..\/polyglotclasses-1.3.5.jar/" \
-e "s/.*$jasmin.jar=$.*/\1..\/jasmin-dev\/lib\/jasminclasses-trunk.jar/" \
> soot-dev/ant.settings

# Change into the soot-dev directory and build the
# sootclasses-trunk.jar file, and change back out of the directory:
cd soot-dev
ant classesjar
cd ..

cp soot-dev/lib/sootclasses-trunk.jar .

A HotSpot Java Error, a Bus Error and a Segmentation Fault

Mathias — Sat, 30 Jan 2010 20:10:40 +0000

When I run Soot to create a call graph of DrJava, I get the aforementioned HotSpot Java error on Windows with Java 1.6.0_18.

On Mac OS X 10.4 with Java 1.5.0_19, I get a “Bus error” (Java exit status 138).
On Red Hat Enterprise Linux 5 with Java 1.6.0_18, I get a “Segmentation fault” (Java exit status 139).

Fun, fun! At least it’s consistently not working. They probably all have the same cause.

More Details on Soot and -allow-phantom-refs

Mathias — Fri, 29 Jan 2010 16:24:03 +0000

In the previous post I mentioned that I’m trying to create a call graph of all of DrJava using Soot. Since DrJava is a cross-platform application, there are classes that get compiled and used only on certain operating systems. The classes in the com.apple.eawt package, for instance, are only used on the Mac.

That means that Soot doesn’t normally find these classes when generating the call graph with Sun JDKs:

resolving [from .class]: edu.rice.cs.drjava.platform.MacPlatform$1
Exception in thread "main" java.lang.RuntimeException:
couldn't find class: com.apple.eawt.ApplicationListener
(is your soot-class-path set properly?)
    at soot.SootResolver.bringToHierarchy(SootResolver.java:184)
    at soot.SootResolver.bringToSignatures(SootResolver.java:219)
    at soot.SootResolver.bringToBodies(SootResolver.java:260)
    at soot.SootResolver.processResolveWorklist(SootResolver.java:135)
    at soot.SootResolver.resolveClass(SootResolver.java:124)
    at soot.Scene.loadClass(Scene.java:390)
    at soot.Scene.loadClassAndSupport(Scene.java:375)
    at soot.Scene.loadNecessaryClasses(Scene.java:963)
    at soot.Main.run(Main.java:169)
    at soot.Main.main(Main.java:145)

Setting the Soot -allow-phantom-refs option doesn’t really help; it gets past the initial stages, but later still has errors:

Exception in thread "main" soot.AbstractSootMethodRef$ClassResolutionFailedException:
Class com.apple.eawt.ApplicationEvent doesn't have method setHandled([boolean]) : void;
failed to resolve in superclasses and interfacesLooking in com.apple.eawt.ApplicationEvent
which has methods []
    at soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:135)
    at soot.AbstractSootMethodRef.resolve(AbstractSootMethodRef.java:95)
    at soot.jimple.internal.AbstractInvokeExpr.getMethod(AbstractInvokeExpr.java:54)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.getImplicitTargets
        (OnFlyCallGraphBuilder.java:234)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processNewMethod
        (OnFlyCallGraphBuilder.java:182)
    at soot.jimple.toolkits.callgraph.OnFlyCallGraphBuilder.processReachables
        (OnFlyCallGraphBuilder.java:81)
    at soot.jimple.toolkits.callgraph.CallGraphBuilder.build(CallGraphBuilder.java:84)
    at soot.jimple.toolkits.callgraph.CHATransformer.internalTransform(CHATransformer.java:43)
    at soot.SceneTransformer.transform(SceneTransformer.java:39)
    at soot.SceneTransformer.transform(SceneTransformer.java:45)
    at soot.SceneTransformer.transform(SceneTransformer.java:50)
    at dk.brics.soot.callgraphs.CallGraphExample$2.internalTransform(CallGraphExample.java:88)
    at soot.SceneTransformer.transform(SceneTransformer.java:39)
    at soot.Transform.apply(Transform.java:89)
    at soot.ScenePack.internalApply(ScenePack.java:43)
    at soot.Pack.apply(Pack.java:114)
    at soot.PackManager.runWholeProgramPacks(PackManager.java:409)
    at soot.PackManager.runPacks(PackManager.java:329)
    at soot.Main.run(Main.java:202)
    at soot.Main.main(Main.java:145)

What I did instead was make the Apple classes available on Windows and Linux as well, just on the Soot classpath (they aren’t actually loaded by the JVM), but then I run into an 8-year-old Java bug in the garbage collector. Fixing Soot is more likely than fixing the JVM.

Update

After checking out Soot from the svn repository and building it from scratch, the Soot problem has gone away, but now I still run into the 8-year-old Java bug in the garbage collector.

Java Bug 4396719 – Mark Sweep stack overflow on deeply nested Object arrays

Mathias — Fri, 29 Jan 2010 11:39:07 +0000

I’m trying to create a call graph of all of DrJava using Soot. DrJava is a cross-platform application that has some classes that get compiled and used only on certain operating systems; for example, the com.apple.eawt package is only used on the Mac. That means that Soot doesn’t normally find these classes when generating the call graph with Sun JDKs. Setting the Soot -allow-phantom-refs option doesn’t really help; it gets past the initial stages, but later still has errors. What I did instead was make the Apple classes available on Windows and Linux as well, just on the Soot classpath (they aren’t actually loaded by the JVM).

Now I’m getting a HotSpot Java error. Except for memory addresses, it is identical to this bug 6849033, filed in June 2009. The bug report, however, is closed because it is a duplicate of bug 4396719 – Mark Sweep stack overflow on deeply nested Object arrays… which isn’t in the database.

Why is that bug not in the database? Probably for security reasons, which isn’t immediately obvious. The fact that the original bug report to which all other bugs are referring isn’t available makes it hard to figure out what’s going on. What I find really shocking, though, is that the first bug I can find that lists the ominous bug 4396719 as original bug report is from February 2002: bug 4641910. That means this bug has been known and not fixed for eight years!

Some other duplicate bug reports provide a description of the problem:

The problem is in the Garbage collection subsystem, dealing with the very deeply nested arrays (an array who’s element is an array who’s element is an array…)

This also makes it clear why there are security concerns that lead to the removal of the bug report: It is fairly simple to write Java code that is perfectly legal and that passes the Java verifier, but that will cause the JVM to crash. This can be used for a denial-of-service attack in Java plugins.

The source for exploits is out there, this bug has been known for over eight years, some duplicate bug reports still describe the problem. Security through obscurity won’t work, especially not if you are this sloppy. I’m disappointed, Sun!

Another Possible Improvement

Mathias — Tue, 12 Jan 2010 22:04:15 +0000

On the other hand, I think I can re-enable checking if the event thread has finished and generating EventThreadStillProcessingErrors in the “update” Runnable that sets the test thread group the event thread uses, at least in certain cases.

It is possible that test A has generated the EventThreadStillProcessingError by putting a long Runnable aRunnable on the event queue. When test B starts executing, it puts an update Runnable updateB on the event queue, but it doesn’t execute yet.

If aRunnable finishes now and updateB executes while test B is still running, we can enable checking the event thread again. The event thread has “caught up” with the tests, so to speak.

If, on the other hand, test B finishes before aRunnable finishes, then test C will begin and enqueue an update Runnable updateC. Now aRunnable finishes and updateB executes. Here we clearly don’t want to enable checking, because test C is already executing.

So, if the test’s thread group and the new thread group for the event thread are identical, we can re-enable checking the event thread, because that means the event thread has caught up sufficiently.

Another Possible Problem

Mathias — Tue, 12 Jan 2010 21:29:05 +0000

I think I have just realized that this still isn’t good enough. Now we know that there aren’t any more events, but it is conceivable that a Runnable executing just before the token Runnable has started new threads. Those threads could fail, or add new “token” Runnables. It seems like the whole thing needs to be put in a loop.

New Release of ConcJUnit: 20100112

Mathias — Tue, 12 Jan 2010 21:28:42 +0000

I’ve just made a new release of ConcJUnit: 20100112. This release contains an important addition that I had been thinking about for a while.

ConcJUnit already detected failures and uncaught exceptions in the event thread, but since the event thread is a daemon thread started by the system, it is not part of the “join” and “lucky” checks. It is not required to join the event thread with the test’s main thread (in fact, it’s not really possible, since there is no way to terminate the event thread), and that also means that I do not check if the event thread finished processing.

That was a problem, of course. It was possible to put a Runnable on the event queue and then end the test, resulting in a success, even though the code in the Runnable may still fail.

I have now added code that checks if the event thread is running, and if that is the case, we check if the event queue is empty, as it should be. If it isn’t, then we issue an EventThreadStillProcessingError, which is a subclass of a NoJoinError.

However, an empty event queue does not guarantee that the event thread has finished processing. There way still be a Runnable executing in the event thread; there just aren’t any more events queued up after it. So we need to make sure that there isn’t an event being processed right now; I currently do that by adding a “token” Runnable to the event queue and requiring that it executes immediately¹.

But even if the token Runnable gets to execute right away, it isn’t guaranteed that the test’s events have all been processed. We also have to ensure that after we checked that the event queue was empty and before the token Runnable began executing, no additional Runnable objects were added to the event queue. Those additional events would have been added after the token Runnable, so inside the token Runnable we check again if the event queue is empty.

If the token Runnable executed immediately and the event queue is still empty when it executes, then we know that there aren’t anymore events that need to be processed and that could fail, and the test has completed in its entirety. We already checked that there aren’t any more regular threads around that could add new events, and the event thread has finished processing all Runnables.

When a EventThreadStillProcessingError is generated, then the event thread is still executing code belonging to a test that has just ended. I didn’t want to let the test wait for the event thread to finish, I want to allow it to move on. This is sort of a greedy process: Let’s run as many tests as we can. Waiting for the event thread, if not specified by the test code, could mean waiting forever if the event thread is deadlocked. However, if it isn’t deadlocked, and code there is still making progress, then it may also still fail after a new test has already started to execute. The event thread is shared among all tests, so I had to make sure that a failure in the event thread caused by a Runnable belonging to the previous test doesn’t fail the test currently executing.

I do this by maintaining a field containing the test thread group belonging to the current Runnable in the event thread. If the event thread is not running yet, then that field is updated directly at the beginning of each test. If the event thread is running, then we want all Runnables already in the event queue to still notify the test group of the previous test. All future Runnables, however, should use the current test’s thread group, so we update the field in an “update” Runnable which will execute when all Runnables belonging to the previous test have been processed.

Of course, if the event thread is deadlocked, then the update Runnable will never execute. This isn’t any worse, though, than JUnit already behaves. ConcJUnit will still allow tests that do not need the event thread to execute. When a test is executed that requires the event thread, for example by executing a invokeAndWait, then that test will hang. But at least there will have been a EventThreadStillProcessingError pointing out which test is responsible for it.

Another small problem is that once an EventThreadStillProcessingError has been generated, I do not want all following tests to also fail with that error. The event thread may still contain Runnables from the first test that was flawed that way, for example if the event thread is deadlocked. Therefore, once an EventThreadStillProcessingError has occurred, checking whether the event thread has finished is disabled. That means that only one EventThreadStillProcessingError will ever be generated. Later tests that also have this problem may go undetected until the first test has been fixed.

Footnotes:

Immediately practically means “very quickly”; currently within 100 ms. That’s not exactly the same, but hopefully close enough. [back]

Submitted Publication Version of SIGCSE 2010 Paper

Mathias — Fri, 04 Dec 2009 22:10:51 +0000

I just submitted the publication version of our SIGCSE 2010 paper, Test-First Java Concurrency for the Classroom.

Now I’m waiting for the copyright form to be sent, and I’m wondering why that’s not done automatically…