penberg's posterous

Jato status update for August 2011

Wed, 31 Aug 2011 03:51:00 -0700

In August, people have mostly wrapped up their Google Summer of Code projects.

Ana Farcasi added a SSA-based array bound check elimination optimization. It does not work with loops so we haven't seen major speed gains. Ana is working on improving the optimization to include loops as well.

Ankit Laddha added support for more bytecodes (istore, iadd, and isub) to the ARM architecture port. Likewise, I was able to fix trampolines in the PowerPC port which now is able to successfully JIT and execute iconst and ireturn bytecodes. There's quite a bit of work to be done for both architectures, so people interested in hacking on JVM on ARM and PPC are more than welcome to join the effort.

Theo Dzierzbicki was finally able to make the verifier is fully functional. It's limited in scope but is able to detect some classfile corruption and throw VerifyError:

$ ./jato -cp test/functional corrupt/CorruptedMaxLocalVar
error: corrupt/CorruptedMaxLocalVar: could not load
Exception in thread "main" java.lang.VerifyError: Reference to a too high local variable
   at java.lang.VMClassLoader.defineClass(Native Method)
   at java.lang.VMClassLoader.defineClassWithTransformers(VMClassLoader.java:428)
   at java.lang.ClassLoader.defineClass(ClassLoader.java:471)
   at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:83)
   at java.net.URLClassLoader.findClass(URLClassLoader.java:617)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:341)
   at java.lang.ClassLoader$1.loadClass(ClassLoader.java:1112)
   at java.lang.ClassLoader.loadClass(ClassLoader.java:293)

Finally, Nikhil Sarda resumed Jato hacking after few months of silence fixing up some bugs and adding more test cases. He also announced on IRC that he's interested in hacking on our own garbage collector which hasn't seen much development in over a year.

That's it for August!

Permalink | Leave a comment »

Jato status update for July 2011

Sat, 13 Aug 2011 00:53:00 -0700

Here's a summary of what's been going on in Jato development in July. There has been 129 commits merged:

70 Pekka Enberg
27 Ana Farcasi
25 Ankit Laddha
5 Theo Dzierzbicki
2 Balagopal

SSA and optimizations. It's pretty insane what Ana Farcasi has been able to do in just one month. She implemented SSA-based dead code elimination optimization and fixed tons of issues in the SSA conversion code. Both are now enabled by default and the JIT also does simple array bounds check elimination (also implemented by Ana).

Verifier. Theo Dzierzbicki's verifier patches are now merged to master. It verifies some simple error cases but the infrastructure should be in pretty good shape for future improvements. There's still some issues with actually throwing proper exceptions upon verify errors and there hasn't been updates to the code in the past few weeks.

Inline caching hasn't changed since June. Balagopal has been doing performance analysis on the code and is currently looking at method inlining optimizations.

ARM. Ankit Laddha has made excellent progress on the ARM port and we're actually JIT'ing some simple bytecodes such as iconst and ireturn. There's still lots to do so help is much appreciated! We're especially interested in knowing how things work on ARM hardware as we've only run Jato with QEMU in Scratchbox.

PowerPC. I was inspired by Ankit's progress on ARM so I dug up my old PowerBook G4 and resurrected the PPC port. I was able to copy-paste much of Ankit's ARM code under arch/ppc and started hacking on trampoline support. Trampolines sort of work but there's still some register clobbering issues so we're not able to succesfully JIT bytecodes yet. If you're intereted in helping out, let me know and I'll help you get started.

x86-64. I've also been squashing bugs in the x86-64 port and gotten more tests to run. The x86-64 port needs more love and I think we need to fix method tracing and other infrastructure to make debugging easier. Hopefully this will be easier once Eduard Munteanu's work in moving more code generation into the instruction selector is finished.

VM startup time. Ana has been speeding up SSA code and as part of that, I've also been looking at Jato startup performance profiles and speeding up things here and there which has made startup times faster. Most of our problems are related to JIT compiler data structures that are quite frankly way too memory hungry. Fortunately this doesn't matter that much for long-lived applications.

That's it! As always, if you're interested in helping out Jato by testing, hacking, or improving the documentation, please drop by the #jato channel on irc.freenode.net.

Permalink | Leave a comment »

Jato status update for June 2011

Sat, 02 Jul 2011 06:50:00 -0700

Another month has passed and Google Summer of Code is in full swing. Here's a brief summary of interesting developments in Jato since May.

Monomorphic inline caching for 32-bit x86 has been merged to master and enabled by default. It doesn't seem to either improve or degrade performance so there's still some tuning left to do for Balagopal.

SSA conversion from and LIR has been merged to master. It's still disabled by default because some regression tests are known to break but you can enable it with '-Xssa' if you want to give it a shot. Ana has already begun experimenting with SSA-based dead code elimination optimization so we'll probably see some performance benefits from her project in the coming month.

ARM porting project was stalled a bit in June but Ankit has managed to implement instruction selection for EXPR_VALUE and EXPR_LOCAL so far. This hasn't been an easy project to work on but I'm hoping we'll see end-to-end arm JIT support for some bytecodes in July.

The verifier project hasn't resulted in any patches in Jato's git master yet.

In related news, I've added a dead simple interpreter in vm/interp.c that supports the nop and return bytecodes. You can enable the interpreter with '-Xint' command line option and run test/functional/jvm/EntryTest.j with it! Admittedly, we're cheating a little bit as GNU Classpath initialization is JIT'd at the moment. That said, if anyone is interested in hacking on a JVM interpreter, drop by #jato on irc.freenode.net and I'm happy to help out. I think the feature is going to be important in future porting efforts and quite possibly reducing Jato startup times.

Permalink | Leave a comment »

GNU Classpath five months later

Thu, 26 May 2011 08:23:00 -0700

It's now been five months since I wrote my slightly controversial Future of GNU Classpath blog post so I thought I'd take the time to whine some more. It seemed to have a net positive effect the last time.

I have had GNU Classpath commit rights for the past four months or so and have committed total of 9 patches to CVS HEAD. I've fixed compatibility problems that prevented the use of JRuby, Jython, and Redline Smalltalk. It's not a huge amount of work but I've still been able to help GNU Classpath become more useful to end-users and be more compatible with OpenJDK.

So what do I think need to improve in GNU Classpath still?

CVS. It's still painful to use. I think most of the remaining core developers agreed to switch to Mercurial or Git but nothing has happened after that.

No release in two years. Having no recent release is a problem for Jato, at least. CVS HEAD is already in much better shape than the latest 0.98 release which is already over two years old. Anyone interested in trying out Jato now needs to use CVS to fetch the latest sources which is an unnecessary barrier for newcomers.

Automated tests. Mauve is great. It has tons of important compatibility test cases. However, Mauve has couple of problems: (1) running the whole test suite is slow, (2) not all tests pass with OpenJDK, and (3) the output is very verbose which makes it difficult to notice test breakage. Malva has caught bugs in GNU Classpath, Jato, Jam VM, and CACAO. It fixes most of the problems I see in Mauve but it's of limited use because the number of test cases is still so small.

JDK APIs. The 1.7 release of OpenJDK is close and there's bunch of shiny new APIs queued for 1.8. The cold reality is that with every new JDK release, GNU Classpath becomes less and less relevant unless it's able to implement at least the major new APIs. JRuby, for example, is switching over to the invokedynamic APIs that are introduced in 1.7 so in not so distant future, we won't even be able to compile it with GNU Classpath.

JVM support. CACAO and JamVM support OpenJDK now and most of the interesting open source work seems to happen in the IcedTea project. This is a big problem because there's very little positive pressure from JVM developers to fix up GNU Classpath compatibility issues. One possible solution here is to make GNU Classpath binary compatible with OpenJDK so that any JVM out there that supports the OpenJDK VM ABI would be able to use GNU Classpath out-of-the-box.

I guess that's enough whining. See you again in six months!

Permalink | Leave a comment »

Jato status update for March - May 2011

Tue, 24 May 2011 10:35:00 -0700

Jato was accepted to Google Summer of Code 2011 and work on the following projects has now started:

SSA form support (Ana-Maria Farcasi)
Inline caching (Balagopal)
ARM architecture port (Ankit Laddha)
Bytecode verifier (Theo Dzierzbicki)

Meanwhile Eduard-Gabriel Munteanu and Sergey Mashkov squashed bugs in the x86-64 port and Joonas Reynders and Nikhil Sarda implemented bunch of missing core Java and JNI APIs. Tomek Grabiec and Vegard Nossum also threw in some critical bug fixes putting us one step closer to a new release.

Needless to say, I'm looking forward to an interesting summer and hopefully an impressive release!

Permalink | Leave a comment »

Jato is participating in Google Summer of Code 2011!

Sun, 20 Mar 2011 01:47:00 -0700

Jato will be participating in Google Summer of Code again this year! If you're a student looking for interesting things to hack on, look no further! You can find our organization profile here:

http://www.google-melange.com/gsoc/org/show/google/gsoc2011/jato

There's lots of interesting areas to work on. In particular, the following are pretty high on the list:

JIT compiler optimizations (SSA in particular)
Invokedynamic
ARM and x86-64 architecture ports
Exact garbage collector (we're using boehmgc now)

You can find the full list of project ideas here:

http://www.jatovm.org/projects.html

And as always, we're also open to projects that are not on the list. Feel free to drop by at #jato on irc.freenode.net or send email to penberg@kernel.org to discuss your ideas and ask questions!

Permalink | Leave a comment »

Jato status update for February 2011

Fri, 25 Feb 2011 02:45:00 -0800

Lots of cool things happened in Jato in February!

Joonas Reynders completed his rework on JNI. You can now build native code against Jato and use the JNI API from C code.
Class.getDeclaredAnnotations() mostly works now.
JNI mostly works on x86-64 now.
60% of our test suite passes on x86-64. Up from 50% in January!
I started some experimental work to investigate if it’s possible to support Dalvik DEX format in Jato. You can find some preliminary DEX classloading code in experimental/dalvik branch on Github

In related news, I fixed some problems in GNU Classpath that were blocking Jython from running under JamVM. I also fixed a problem in String.format() that was causing JRuby to fail to start up. JRuby doesn't work correctly yet due to some bug in GNU Classpath regexp code.

Permalink | Leave a comment »

Jato and Malva status update for January 2011

Wed, 26 Jan 2011 00:00:00 -0800

Things have been little quiet over the past two months but we've managed to get some work done for Jato and Malva. I was hoping to do a release at the beginning of January but decided to wait for the annotation support to work properly before doing it.

Jato

I've been hacking on annotation support. Most of the classfile parsing is now done and Class annotation reflection API is under development.
Joonas Reynders started working on JNI regression tests
Joonas Reynders, Tomek Grabiec, and myself added some missing Classpath VM integration APIs.
I've fixed "make check" to only run the passing tests on x86-64. 50% of all the tests pass now.

Malva

Joonas Reynders added test cases for java.net.InetAddress.
I added more test cases for java.lang.Class.

In related news, I became a GNU Classpath committer on January 21 and hope to help getting pending patches reviewed and merged. I'm also looking at fixing issues in GNU Classpath that have been found by test cases in Malva.

Permalink | Leave a comment »

What's the future of GNU Classpath?

Tue, 07 Dec 2010 11:07:00 -0800

The number of commits in GNU Classpath peaked at 3193 in 2006 (as measured from a git mirror of the CVS repository). Activity has since dropped significantly with an all time low of 30 commits in 2009. With 31 commits and counting this year, things aren't really improving. GNU Classpath used to be the essential free Java runtime library but that's all changed now. Ubuntu, for example, has dropped the GNU Classpath package and only ships the OpenJDK version of CACAO. Another prominent alternative JVM, JamVM, seems to be also migrating to OpenJDK. It looks like the community is moving over to OpenJDK and GNU Classpath development is grinding to a halt.

But with OpenJDK licensed under the GPL, do we still need GNU Classpath to be actively developed? Thinking about the killing of OpenSolaris, Harmony TCK dispute, and the Android lawsuit I think there's enough doubt not to bet the future of free Java on OpenJDK alone. There's also probably something to be said about the dangers of software monoculture as well but the bottom line is that it's still important to have a community-driven project around free Java if don't want big vendors to control its destiny.

So what do I think needs to happen with GNU Classpath?

The CVS repository needs to be migrated git or Mercurial. I mean, just getting the GNU Classpath sources via cvs checkout is painful enough to avoid contributing to the project not to mention how much problems it causes for developers that don't have commit rights to the centralized repository!

Patches need to be reviewed and merged more quickly. There's lots of unmerged patches waiting in bugzilla and the mailing list. When I tried to help out and get one of those patches merged, it took two whole months of waiting before it ended up in CVS. That's too long time to wait for your patch to be merged and is likely holding back potential new contributors.

More automated tests for compatibility testing. It's pretty obvious by now that there's not going to be a freely available Technology Compatibility Kit (TCK). That's why it's so important to write automated compatibility tests against OpenJDK and make sure they pass with GNU Classpath as well. The Mauve project seems to have been abandoned which is why I've started a new project called Malva that attempts to write compatibility tests for the core Java APIs.

Java 1.6 and 1.7 APIs need to be implemented. GNU Classpath APIs are currently stuck at Java 1.5 level. There's already applications out there that use the Java 1.6 APIs and the situation is only going to get worse as time passes by. It's therefore crucial that work on Java 1.6 and 1.7 APIs starts as soon as possible for GNU Classpath to stay relevant.

There's so much software written in Java that it's unlikely to go away any time soon. There's also some really cool development happening in the alternative JVM language space (Scala, Clojure, and JRuby, for example) which hopefully makes the JVM a relevant platform in the future. I do think OpenJDK is great but I don't think we should rely on it alone if we want to make sure Java stays a free and useful platform in the future as well.

Permalink | Leave a comment »

How does Jato execute Java classes?

Fri, 03 Dec 2010 07:02:00 -0800

Each standalone Java application has an entry point that's the main() method of some user-defined class. For example, a "hello, world" application looks something like this:

public class Hello {
    public static void main(String[] args) {
      System.out.println("hello, world");
    }
  }

After the source code is compiled with javac to a Hello.class classfile, you execute the class as follows:

java Hello

Now there's all sorts of things Jato (like every other virtual machine) needs to do to initialize itself but how does execution actually get transferred to the Hello.main() method? Looking at the main() C function of Jato itself in vm/jato.c we see this piece of code:

switch (operation) {
  case OPERATION_MAIN_CLASS:
          status = do_main_class();
          break;
  case OPERATION_JAR_FILE:
          status = do_jar_file();
          break;
  }

As we're interested in Java class execution, we dive into do_main_class() function where we find

struct vm_method *vmm = vm_class_get_method_recursive(vmc,
          "main", "([Ljava/lang/String;)V");
  if (!vmm) {
          fprintf(stderr, "error: %s: no main method\n", classname);
          return -1;
  }

  [... snip ...]

  void (*main_method_trampoline)(void *)
          = vm_method_trampoline_ptr(vmm);
  main_method_trampoline(args);

Here we do two things: (1) look up a "struct vm_method" for the user-specified class Hello.main() method and (2) call a function pointer returned by vm_method_trampoline_ptr() which transfers control to the JIT compiled machine code of Hello.main() method. So what is a trampoline then? A trampoline is a small per-method piece of code that acts as the receiver method for methods that have not yet been compiled. For details, see arch/x86/emit-code.c::emit_trampoline() how individual trampolines are generted. The heart of it all is jit/trampoline.c::jit_magic_trampoline() function that determines the real target method by compiling the method or, in the case of native methods, looks up the address of the called native function. The same kind of approach is also used by VMs such as Mono and Kaffe.

In summary, Jato executes the Java main() by looking up an internal struct vm_method representation of it and calling it's trampoline function. The trampoline function then takes over and compiles the main method and executes the machine code. This process continues recursively until we either invoke System.exit() or return back to the VM function do_main_class() that called the first trampoline function.

Permalink | Leave a comment »

Malva status update for October 2010

Sun, 31 Oct 2010 06:12:00 -0700

Joonas Reynders has been busy cranking bunch of new test cases for Malva. Looking at JamVM 1.5.3, CACAO 0.99.4, and Jato 0.1.1, none of them run all Malva test cases:

penberg@jaguar:~/src/malva$ make check JAVA="jamvm"
  CHECK
malva/java/lang/RuntimeTest: Test FAILED
make: *** [check] Error 1
penberg@jaguar:~/src/malva$ make check JAVA="java -cacao"
  CHECK
Exception in thread "main" java.lang.NullPointerException
        at java.lang.Thread.getAllStackTraces(Thread.java:1504)
        at malva.java.lang.ThreadTest.testGetAllStackTraces(ThreadTest.java:38)
        at malva.java.lang.ThreadTest.main(ThreadTest.java:294)
malva/java/lang/ThreadTest: Test FAILED
make: *** [check] Error 1
penberg@jaguar:~/src/malva$ make check JAVA="jato"
  CHECK
Exception in thread "main" java.lang.UnsatisfiedLinkError: java/lang/VMRuntime.traceInstructions(Z)V
   at java.lang.Runtime.traceInstructions(Runtime.java:634)
   at malva.java.lang.RuntimeTest.testTraceInstructions(RuntimeTest.java:101)
   at malva.java.lang.RuntimeTest.main(RuntimeTest.java:122)
malva/java/lang/RuntimeTest: Test FAILED
make: *** [check] Error 1

NetworkIntefaceTest was disabled because GNU Classpath doesn't implement that API at all. That said, I'm impressed with the amount of compatibility problems we're finding!

On a related note, I "forked" GNU Classpath to be able to fix problems related to Jato faster. I hope all the changes make it to mainline in one form or another.

Permalink | Leave a comment »

Introducing Malva - a test suite for alternative JVMs

Thu, 23 Sep 2010 06:51:00 -0700

Malva is a new Java core API test suite that's primary goal is to find compatibility problems in alternative JVMs such as CACAO, JamVM, and Jato. Malva is a companion project to the Mauve Project with focus on Java APIs that require implementation on the virtual machine side.

If you have OpenJDK or Oracle Java installed on your system, running the test suite is as simple as:

git clone git://github.com/penberg/malva.git
cd malva
make check

All tests should pass.

To run the test suite under an alternative JVM, use

make check JAVA=jamvm

and to use an alternative Java compiler for building the test suite, use

make JAVAC=ecj

Malva is a brand new project so there aren't that many tests yet. It has found plenty of problems in Jato that I'm planning to fix. I'm unable to get CACAO working but I'm glad to see that all tests pass with JamVM!

If you're interested in helping out, feel free to drop by at #jato channel on irc.freenode.net or send me email or patches at penberg@kernel.org.

Permalink | Leave a comment »

Jato 0.1.1 released, what's next?

Sat, 18 Sep 2010 12:15:00 -0700

I just released Jato version 0.1.1. It contains work from Tomek Grabiec and myself to improve performance and compatibility across board. Jato is now capable of running Eclipse and bunch of other big applications on 32-bit x86 Linux so what's next?

The biggest limitation of Jato is that it doesn't run on 64-bit x86 machines. I've also been working on that recently but there's still plenty of things to work on. I've been pondering about introducing an interpreter to Jato to at least make things work on 64-bit.

Another thing that's going to be a problem in the long-term is GNU Classpath. I've heard that it's being dropped from Ubuntu 10.10 beta. There hasn't been a new release of GNU Classpath for a while now and it seems everyone has moved on to OpenJDK and IcedTea. I'd really love to stick with GNU Classpath but it seems that we need to at least support OpenJDK to make Jato a viable option.

On performance side of things, we're actually doing pretty well. I did some benchmarking and compared Jato to CACAO, JamVM, and Hotspot. We're generally faster than JamVM which doesn't have a JIT and are actually pretty close to CACAO in some benchmarks. To improve performance further, we need to implement array bounds check elimination, inlining, and inlining. Our locking functions are pretty fast now but we can make them even faster with lock elision.

I recently started to work on SSA form conversion that will allow us to write certain optimizations easier. It's in really early stages, though, and there's plenty of things to do before we're going to get any benefit from it. Another obvious performance bottleneck is Boehm GC. It's not all that bad but we can see GC allocations show up high in benchmark CPU profiles.

There's also plenty of bugs to fix. JNI API is not complete and core VM APIs like reflection that GNU Classpath relies on are also incomplete. Jato is not really yet in a state where things Just Work (™) but it's good to see Jato grow up. It's pretty impressive how much work we've been able to accomplish although we didn't make it to Google Summer of Code this year. I'm looking forward to another interesting year with Jato!

Permalink | Leave a comment »

How I Learned Myself a Haskell

Sat, 24 Jul 2010 06:46:00 -0700

I first ventured into the strange land of Haskell in late 2007. I was especially excited by Parsec, a parser framework for Haskell, and wanted to seeif I could write a simple compiler with it. Unfortunately I quickly hit a brick wall unable to write even the simplest program and quietly moved to other things. In the late 2009, I again picked up Haskell from a suggestion of my colleague. This time, armed with Programming in Haskell and Real World Haskell, and Erik Meijer's Functional Programming lecture series videos I was determined to get the bottom of things.

The first thing I learned was that Haskell is whitespace significant like Python, for example. Significant whitespace means that you define program structure with whitespace, not with explicit syntax (e.g. curly braces) like in most mainstream languages. This little detail that had escaped be earlier helped me immensely - I was now able to write non-trivial functions! The second important lesson was that Haskell has type inference which means that the compiler is able to deduce types for you. For some reason, though, writing out function types explicitly is considered good Haskell style (according to Erik Meier anyway).

With basic language features figured out, I started looking at how to solve problems in functional way. I had a lot of difficulties gasping the proper mindset until I realized that functional programming is a form of declarative programming. Combined with the fact that Haskell evaluates everything lazily, I finally understood why I was having such a hard time with the language. Instead of writing programs as a series of instructions, I should look at how to combine functions - just like in mathematics - to get the result I wanted. With this realization, the basic building blocks in Haskell Prelude started to make sense.

The final obstacle in my understanding of Haskell was, rather unsurprisingly, monads. Learning about them through category theory and other abstract descriptions were a dead end as were the various "explain monads by a metaphor" articles on the internet. What helped me the most was finally giving up trying to "understand monads" and settling on the fact that "a monad is constructed by defining two operations (bind and return) and a type constructor M that must fulfill several properties to allow the correct composition of monadic functions" (Wikipedia).

I'm still a complete Haskell newbie but the journey so far has been an eye opening experience. The difference between imperative and functional form wasn't news to me - in theory. In practice, my brain was hard-wired to imperative form which is why Haskell seemed borderline insane. Once I got around the basics and understood the functional programming is a form of declarative programming things started to get easier. It's been an interesting journey so far but well worth it. As Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing."

Permalink | Leave a comment »