Over last 12 years, Java has become almost de facto in application development paradigm. Initial days were complaining about the performance of Java programs. However there is no doubt that enormous efforts that have been put in optimization of Java compiler and JVM implementations, have given handsome returns. But we know, rather we need to know, that there is an upper limit to this optimization for performance, being implemented as a software. Despite Java’s wide acceptance, Java Virtual Machines are limited to be software deployments. There is an emerging need, to have Java Virtual Machine in  hardware.

Fortunately the space is not an entirely unexplored territory. There were several efforts to implement Java processors and including PicoJava, one of them from Sun Microsystems. It seems a very promising concept and it should become more and more relevant in days to come. Imagine a system with many cores, for example ‘SUN UltraSPARC T2‘ that has 8 cores per CPU. Now all these cores are identical and a server with 8-way configuration would have 64 cores. This kinds of systems leave a lot of room for something called as ‘Domain-specific Processors’, hence it makes lot of sense to have four dedicated Java processors part of the system. One of such example is presented by IBM for its System Z Application Assist Processor(zAAP). Primary benefit of having such processors would be their specialization. Such processors can be optimized to a larger extent, they can be upgraded frequently and would be cheaper. Apart from that, these processors leave the main general purpose processors free to do their tasks. Thus a Java Processor can be a co-processor to your main processor. Remember the known examples such as ‘Intel 387′ or today’s Graphics Processing Units (GPUs). Checkout some benchmarks for IBM’s zAAP.

Another very interesting initiative is from Bea Systems, that talks about JVM Hypervisor. This can, meanwhile, provide some breathing space. The idea was, I guess, first presented by Joakim Dahlstedt (CTO of Bea) at JavaOne 2006. One can find PDF of the presentation here - “Bare Metal”—Speeding Up Java™ Technology in a Virtualized Environment.

I came across an interesting post which compares the benchmarks of two virtual machines: Parrot and NekoVM. The post discussed various issues except the convenience that Parrot offers. There are, of course, various concerns and constraints and no one should deny them. However we need to prioritize these concerns. For few, performance might be the concern, whereas scalability, reliability, productivity in terms of time-to-market, etc are also valid criteria to consider. What is important is to understand the potential of Parrot and to apply it appropriately.

Application virtualization is one area, where Parrot can play very important role. Seamless integration of application-level resources is possible because Parrot is register-based virtual machine, unlike Java Virtual Machine which is based on stack operations. Hence resources can be managed better using Parrot, such that it would soar the overall utilization of resources. One needs the bulky OS virtualization environment with ‘minimal overhead’, just to run the applications. Instead applications themselves can be run in application virtualization environment, such that migration, instantiation, etc can be done on a light-weight basis. Probably the analogy between process and thread is applicable for OS virtualization and application virtualization, appropriately.

I am one of the believers of Parrot Virtual Machine, even though it has not come very far from where it had started and is humiliated sometimes. However the goal to integrate many languages (language run-times, to be precise) is very interesting. I don’t quite understand that why Parrot is still called the Perl6 VM. This is despite the fact that Parrot supports no language currently (including Perl6) and plans to support languages, along side Perl6.

In future, Parrot-like environments would become very useful, especially when domain-specific languages (DSL) would surface out. Ruby has already gathered some attention for this reason, whereas grammars would become first class citizens in Perl6. Imagine the world when lot many useful DSLs would need to interact with each other, such that each DSL has origin in different language and run-time.

Conclusion: (There has to be a conclusion of every discussion.) Despite failures and critique of the past and the present, Parrot VM is becoming more and more relevant for the future. All the best Parrot! One VM to rule them all!