This time recorded on Ubuntu. Did I mention 64bit already?
Do not miss my session at FOTB for a live demo.
Tag Archive for 'Flash'
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.
Despite the fact that ActionScript has a couple of major glitches and missconceptions I think there are also a couple of great key features that force you to write better applications due to the language design.
First of all we have to aknowledge that ActionScript has some great features. Those include implicit getters and setters or method closures for instance. Java 7 will have method closures finally after a lot of argy-bargy about their complexity et cetera. ActionScript developers are used to method closures and are buddy-buddy with them since Flash 4 I think.
But what is the real advantage of ActionScript? Here are my thoughts.
-
Poor Performance
Yes. We have been educated to optimize the hell out of our code. We have been educated to think about our code and how it performs. We have been educated to be creative with our tools, to tinker around. I know that this is not something to be essentially proud of but it led to a lot of creative and astonishing experiments. If you would tell a Java programmer you are still developing object pools they will laugh at you for a good reason. This is where the poor performance is annoying but something is very important: the potential. Think with the mind of a carpetbagger. Shares on the stock-market that never have a downturn are less interesting because there is less profit potential. So why am I talking about this? It is quite simple: Flash has still a lot of potential for growth. Flash did not pass its zenith already like other virtual machines. This makes me very optimistic for the future. There is still so much potential for the growth in performance and I think that Apparat has shown this as well.
-
Forced Asynchronism
ActionScript has no ability to perform blocking operations (despite of AIR). This makes every application responsive. If you load files from an external source like a URL your application will stay responsive because you have to add listeners that react on certain events. I know this is somtimes cumbersome but every good application should make use of asynchronous IO for instance. If people are lazy they will simply spawn a new thread to perform blocking operations which is also okay but less performant. Usually the simple example is a server where you would spawn a new thread for every client. This is the worst you can do and Java tackles this issue with its NIO. However a lot of people do not make use of NIO because they think it is hard to use for common tasks.
-
Events
Events are a great way to achieve concurrency. Some people call this immutable message passing. If your events do not contain state or are immutable, you have a powerful system to tackle concurrency. Basically this is what the EventDispatcher is all about. You add listeners for certain messages to a dispatcher and then you react on a message when it is dispatched to you. Again we have been educated to use a system which forces us to write responsive applications that is not based on synchronization and locks like Java or C++. If Adobe decides to implement multithreading in the Flash Player I hope they will choose to implement the approach of Erlang which is all about immutable events and event dispatchers. The only difference is that Erlang programmers call them actors.
This post is not an ode to ActionScript. There are still major issues like the lack of parameterized types. But I do think that there is a lot of potential. We can grow with the language and we can tackle upcomming issues. Concurrency is one of them, limited resources on a mobile device are another one.
What you have told us is rubbish. The “open web” is really an acronym for Apple’s cash cow supported on the back of a giant tortoise lie. But Steve Jobs said that Flash is responsible for most of the OS X crashes! You are very clever, young man, very clever. But it is lies all the way down.
This evening Kai-Philipp and me were playing around with the Hobnox Audiotool to test some of the upcomming Midi features.
In the middle of the performance we lost the connection to the little cubes and had to restart the Midi bridge between Flash and the devices. It is still in an early stage but a whole load of fun.
The little cubes were provided by our colleague Oliver who is currently reviewing them. They are comming from percussa.com and are able to send CC values based on their orientation.
Please support our campaign Adobe, MAKE SOME NOISE! if you love Flash and music.
