Maybe I should explain a bit what my greater thinking was as regards VM convergence.
In 2003 CPUs hit a wall as regards clock speed. Since then the emphasis has been on adding more cores to processors. Even this trend I don't think can go on forever. Soon processors will be manufactured at around 20nm fabrication process but it is expected to be difficult to go smaller than 16mn due to quantum tunnelling. Even below that a wall is hit because atoms are a certain size and cannot be made smaller. What if a sufficiently expressive bytecode system was developed which could supersede the existing ones while providing an easy mapping of the functionality. If it could be supported natively by the different processor architectures then the processors aught to be able to run it fast. No one would no better than the processor manufacturers, how to optimise for their own processors (I would hope anyway). I believe that CISC processors have a micro code system already which implies that more complex operations need to be broken down into simpler operations implemented in hardware. If programs target this bytecode (though not necessarily meaning the processor allows no other way of operating) then it opens up processor architecture to a whole lot more room for innovation. Architectures could be more 'disposable'. New bold changes could be made (so long as it supports the bytecode) without worrying about breaking compatibility. If an architecture doesn't work out, a different one can be tried. The current landscape of tight binding to processor architecture would never allow for this. This kind of bold experimentation could help squeeze more performance out of processors when increasing clock rate or adding cores is no longer possible. Also the trend of integrating GPUs and other accelerators, these can be utilised in executing the bytecode in a way transparent to the higher levels. I also have a dream of convergence of VM technology so Java, .Net, Flash and JavaScript etc all run on a universal VM which is hardware accelerated. This is just a dream though and I don't know it would ever happen. It would require the different platforms to drop their proprietary byte codes in favour of the Universal one which would be a big battle (even though if there is a mapping between them a tool could just convert the legacy bytecode once and not need to be done every time). As regards the argument that a VM cannot handle multiple bytecodes without emulation I don't see why this need be the case. The JVM has functionality and a bytecode layer which is used to invoke that functionality. I don't see why he bytecode handler could not be made pluggable such that multiple bytecode handlers could plug into the same VM functionality but be used to interpret different bytecodes. This is not converting from one bytecode to another but rather just switching between bytecode handlers depending on which mode the VM is operating in. This works for a software VM but does not lend itself to hardware acceleration because it would be hard for the hardware to accelerate lots of different bytecode formats. Execution of bytecode directly on the processor is already a reality. The ARM 9 processor introduced Java bytecode execution directly in the CPU. This continues with the ARM 11 and I believe later processors too. I would assume that this is why these processors were easily used in Sun Spots. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
