Comments on: The Garthe JVM

By: Tripp Lilley

Tripp Lilley — Fri, 12 Oct 2007 11:53:51 +0000

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…

By: Alex

Alex — Wed, 10 Oct 2007 13:24:23 +0000

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.

By: Niklas Mehner

Niklas Mehner — Wed, 10 Oct 2007 08:32:47 +0000

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.

By: Alex

Alex — Wed, 10 Oct 2007 04:01:06 +0000

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.

By: Michael Schidlowsky

Michael Schidlowsky — Wed, 10 Oct 2007 00:11:28 +0000

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).