I am back home in Germany from my trip to San Francisco where I initially announced JITB at FITC. I did not expect it to get around that quickly and that a quick-and-dirty video filmed with my phone would get so much coverage.
I want to put a lot of things regarding JITB in perspective here as a followup to the various comments that I received via mail, reddit, etc.
Flash Replacement
JITB is not a Flash replacement. Imagine a F1 race car and a family van. The family van comes with air conditioning, a radio and a lot of comfort. For the F1 car you will probably have to wear a helmet and need an engineering team to get it running.
The important factor for me is that JITB will run very fast under certain conditions. A race car is also not a jeep. JITB will not support all features of the Flash Player. If you search for a Flash replacement you might want to take a look at lightspark.
Performance
Java is slow and the world is flat. That being said I will not talk about Java performance. JITB compiles to native Java code with a certain overhead. An ActionScript 3 closure is converted into an anonymous class for instance.
JITB converts ActionScript 3 bytecode to Java bytecode at runtime and performs various optimizations. This way we can leverage the speed of the JVM for ActionScript and get great results.
That being said there is also a problem of course. Startup time is not very good. JITB and its parent project Apparat are implemented in the Scala programming language and written for multi core architectures. The startup costs are high and JITB is only useful for long living applications. However compiling ActionScript to Java can be done AOT. This means you need to deal only with the normal JVM startup time. The Flash Player API is implemented in pure Java.
The compiler used for JITB is doing relatively naive optimizations at the moment. Namely constant folding, copy propagation, dead code elimination and strength reduction. An older proof of concept version I implemented a year ago featured also loop invariant code motion, inline expansion and tail-recursive optimizations. The new compiler framework is very powerful and I will add even more algorithms and a graph coloring register allocator for example. So there is some more NP-complete fun ahead making startup time even worse.
Purpose
We need a Flash Player that performs very fast for special purposes. We could use JITB at Audiotool to render mixdowns of tracks or other companies could use it to run their ActionScript code on the server side. You can use JITB to create an offline application that runs on a client machine. You can hack JITB to do what you want. Someone could potentially write a web framework for ActionScript and you could execute that code on Google App Engine if compiled AOT. And it is definitly possible to create Android applications using ActionScript. JITB’s terrain is everything but the browser in my opinion. However I can imagine that someone would be interested in creating a plugin version. With some clever simple caching algorithms it could make sense to get around startup costs but I am not interested in doing this.
Legal
There are no legal obligations to face since both the AVM2 and SWF specifications are published by Adobe. It is also not illegal to compile code for the JVM.
ActionScript Subset
By “a subset of the language” I really mean the language and not the API. JITB supports currently only statically typed ActionScript code. However the internal language model can be adjusted to support dynamic typing as well and with Java 7 things got even easier. In fact JITB does support dynamic code as long as it is able to infer types correct. Does this mean that I am willing to implement the full Flash Player API all by myself? Hell no.
In the next weeks I will probably create a better example that is easier to understand and get some other stuff ready so that you can try everything for yourself.
9 Comments
Thanks for the clarifications. I’m still excited!
Joa, how does this compare to haxe? I recently had a chance to see Box2D run in flash AS3 (native), flash AS3(haxe), and native binaries via AS3 (haxe). both native app and flash via haxe were awesome performers.
I forgot to add that at least in my attempts to use apparat to improve flash performance, I saw no discernible performance improvements and that the haxe version running native code was hands down the fastest i’ve ever seen anything flash based ever perform.
Hey Jefferey, really cool that you tried haXe. You can use haXe generated SWF files with JITB. haXe does not replace the Flash Player but targets different platforms.
If Nicolas would add a Java backend for haXe you would be able to use your haXe code in the JVM as well.
Apparat does not magically improve the performance of your application (yet). You have to use things like inline- and macroexpansion or the Memory API.
So how do they compare? Hard to tell. It is a completely different approach with a different purpose. Indeed it would have been really cool to have the Audiotool written in haXe but we could not do it for several reasons.
haXe does not help you simply run ActionScript code on a server — only if it was haXe from the beginning. I always try to allow you to use the language and tools you are used to and work only with an exported file (SWF).
@Jeffrey : as Joa stated, haXe is quite different from JITB (and similar other projects) since it allows you to compile natively to other platforms, without going through some emulation mode.
It enables us to have much better performances and also access to native APIs (you’re not restricted to Flash API), but you have to use haXe and cannot simply use AS3.
However, porting AS3 to haXe is not very hard and we are thinking about some tools to make it much more easy.
Interesting project. Yet, if the goal is better performances, I fail to understand why you are doing this in Java instead of C or C++.
Even worse: it really bugs me how you alone created an AVM substitue in Java that performs better than the C++ AVM provided by Adobe…
Don’t get me wrong: you’re doing a very interesting piece of work here. I’m just wondering why the FP team is not able to leverage the work of one single man (no matter how brilliant you are :))
Promethe: If I would do this with C/C++ I would have to implement my own VM with its own GC etc. This is interesting but also time consuming. I also wonder why you would think that a this would run inherently faster.
Writing a really good VM is a hard job. The JVM is really advanced and getting close to its speed is a really hard job as well — and it has been implemented in C/C++ and a lot of other languages. So what do I do? I leverage the JVM and do not have to write my own. I make use of all the work that has been put into Java.
So can you compare this to the work Adobe had to put into the Flash Player? Not at all. They have written a coplete VM (Tamarin) and I use an already existing piece of technology (JVM). The only thing I do is converting a SWF file to a JAR file in layman’s terms.
So I did not create a virtual machine. I just created a transformation so that a different virtual machine (like the HotSpot JVM) can understand SWF files. Which is interesting. Because the code is not “interpreted” on the Java end. I do this only once and emit Java bytecode. And this is indeed quite fast. And it would take you ages as a single person to get to that speed when writing your own VM in the language of your choice.
If you convert the SWF to Java bytecode, why not converting it to native code?
Yes, C++ is inherently faster than Java. I’m not saying you can’t make it slower using C++. I’m saying you can always make it faster using C++. All the things you love about the JVM have a cost. And a pretty big one…
You can refer to the Computer Language Benchmark Game :
http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php
I was just curious about your technical choice. Thank you for making it clearer :)
Without talking about the benchmarks, let me explain the following: ActionScript needs to run in some sort of virtual machine that handles memory allocation and garbage collection. Yes you can implement all this in C/C++ by yourself.
But I am using a virtual machine that is already available: the JVM. It is cross platform, has a huge ecosystem and is a mature project. It is not only about speed but also about interoperability. If I write my own little toy VM, could I deploy it to an Android phone? Could I deploy it to Google App Engine? Probably not.
And do not forget that the JVM is implemented in C as well :)
3 Trackbacks
[...] This post was mentioned on Twitter by Joa Ebert, vic c. vic c said: RT @joa: Putting Things In Perspective: http://blog.joa-ebert.com/2010/08/30/putting-things-in-perspective/ [...]
[...] Visit link: Putting Things In Perspective « blog.joa-ebert.com – Blog of Joa Ebert [...]
[...] Experimenters, Innovators and More Though most nearly every FITC presenter could be classed under this heading, two in particular worth noting are Joa Ebert and Mike Creighton. Joa, whom I overheard impressing both a Flash Player and a Photoshop engineer with his techniques during the speaker dinner, continues to work at a level above most everyone else. He presented on his project Apparat, which as described by Branden Hall, takes your swf, analyzes it and packs it back up, smaller and faster than it was before. You can download Apparat on Google Code. Joa also announced JITB, his version of the Flash Player written in Java. He recently posted a video showing JITB’s performance and posted about what it is and isn’t. [...]