The Garthe JVM
I was reading Mike’s post on how to illustrate the problem with using non-volatile shared state in Java. It reminded me of college where I once had to implement the TCP protocol in C based on a UDP layer and then an FTP app on top of the TCP layer. Since UDP can drop packets, reorder, duplicate, etc you have to deal with all that in the TCP code. Man, I wrote some horrifyingly bad code for that project. It even almost worked!
Anyhow, when the teaching assistants tested it, they inserted an evil UDP layer that would actively drop, reorder, and duplicate UDP packets. We really need the equivalent for the JVM – something that actively reorders your bytecode, does weird thread scheduling, doesn’t update shared memory, etc but stays within JMM constraints. If only Java was open source…. :)
I propose we call this the Garthe JVM in honor of Garthe Knight, the evil twin brother of Michael Knight (both played by David Hasselhoff) on Knight Rider. [Straying increasingly far from the topic, you might also recall that Garth drove KARR, an evil twin of Michael's KITT car.]
We need Duke’s evil twin brother JVM. Lazy web, go build it! Sounds like a good student project.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
This is a pretty cool idea.
But do we really need a modified JVM? Maybe a wrapper that would perform some bytecode magic behind the scenes would suffice? Similar to… well, Terracotta. ^_^
“Sounds like a good student project.”
Your fellow students obviously were a lot more clever than mine…
Since all thread scheduling and stuff below the bytecode level is done in the JVM, I’m pretty sure you’d need to modify the JVM. You could do the instruction reordering in pure byte code but I’m not sure you’d catch the majority of the interesting stuff.
Using Terracotta can in fact help you out with some of the synchronization testing since you are more likely to uncover bad synchronization at configuration or runtime.
I was hoping that IBM’s ConcurrentTesting tool might be just such a tool:
http://www.alphaworks.ibm.com/tech/contest?open&ca=daw-flht-09282007&S_TACT=106AH62W&S_CMP=NEWS
But alas, I ran it on some non thread-safe code that shared variables, and it didn’t cause any staleness…
For pedagogical purposes I’d be willing to just do bytecode manipulation. But I’m not sure how I’d use such a technique for the case I’m most interested in demonstrating (variable staleness).
Looks like an interesting tool though! Good find.
I don’t see how you could do anything with bytecode manipulation to affect the volatile case you were looking to test. Looks like this tool is doing bytecode manipulation from a glance.
Since performance hardly matters for this purpose:
Isn’t it easier to write a simple bytecode interpreter then to modify the JVM?
I once thought about writing a test framework that really executes all possible execution paths/reorderings using an interpreter. But that would create multiple possible execution paths at every instruction and would require some pretty advances merging of execution states to reduce the complexity.
But I really would love to see a testing framework that allows things like:
public void testParallel() {
Interpreter i = new Interpreter();
i.executeParallel(new Runnable1(), new Runnable2());
i.assert(…whatever invariant we expect …);
}
The assertion should have the semantic, that it has to be true for every possible execution path. The heap state in the interpreter could be implemented as some kind of “diff” to the “real” java heap state.
Unfortunately I never found the time to try to implement this.
I think modifying the JVM would probably be easier but that’s just a hunch. I think what you’re really talking about is static analysis and there are certainly tools out there now that will do this kind of analysis. FindBugs does some of this by looking at the bytecode and doing analysis and I know other analysis tools (like JProbe, OptimizeIt, etc) can analyze code while it’s running to determine concurrency problems like data races.
If it’s the anti-Duke, wouldn’t that be Destro, Cobra Commander’s right-hand? Which is apropos, when you consider that it’s designed to destroy your assumptions about the execution context of your code…