OK, so I did my first commit today. You can keep track of the project's code by either browsing it through the web-based viewer (which is usually a couple hours off), or by using the anonymous access:
cvs -d:pserver:firstname.lastname@example.org:/cvsroot/jauvm login
cvs -z3 -d:pserver:email@example.com:/cvsroot/jauvm co -P jauvm
You may be wondering what took me so long. It's true, I've been available since Friday when I last posted, and yet no news.
I've been struggling to solve my first problem: the promised
Monitorclass. That class involved the creation of methods to implement unbalanced
monitorexitoperations. Although those can't be expressed directly in Java, they could easily be implemented directly in JVM bytecode.
To avoid having an extra compile-time dependency, I'd decided to use ASM, defining the class in XML. It all worked pretty well (including a couple of ANT tasks to automate it), until I actually tried running the code, just to find out that the JVM checks to guarantee at runtime that no method does an unbalanced locking operation.
The check was added in 1.4, and is - in my opinion - pretty stupid (sorry clever guys at Sun, but read on). Unbalanced locks are useful, so much so that they are present in rival .NET, and consequently a form of those appeared in 1.5 in the new
This new API though, however “dangerous” for purists, does not suit my needs, because, au contraire of what happens in .NET, this it's not “compatible” with the common
synchronizedblock (in the sense that it's not possible to unbalancedly synchronize on an arbitrary object, you can only lock locks). The API's existence however, proves it can be done - most likely through JNI (I know, that sucks, but that's the JVM we've got).
So the bad news is, in general, synchronization won't work for the time being. Your options will be: using
java.util.concurrent.locks.Locks where you can; or, waiting for the JNI implementation of
Monitor.exit, if you can tolerate JNI.
Note that this affects all synchronization, meaning all the usages of the
synchronizedkeyword (blocks and methods) in interpreted code (and not just the direct usage of the
Monitorclass): these will all throw
UnsupportedOperationExceptions until further notice. This is so, because the
monitorexitopcodes would have themselves to be implemented through
Monitor. Sorry there really seams to be nothing I can do about this.
I won't just give up over this - I knew synchronization would be a problem, and it's really not an unsolvable one (it's just nasty when you can't use plain Java to do safe, simple stuff like this).
I'll move on, for now, and will look into the design of
Frameobjects - which are responsible for keeping the interpreter's state. There are a few different possibilities: some faster, others simpler - as usual. I'll go with the simpler version for now, probably, but I'm trying to abstract enough of the inner workings of frames inside the
Frameclass, to make it easy to latter (as in during or after the summer =) replace it with the faster version.
That's all that's been going on, remember to keep an eye on the repository if you're interested.