You may be interested in the approach that Azul took with their Java optimised processors. These guys know a thing or two about optimising hardware and a VM to work well together:
http://www.theserverside.com/discussions/thread.tss?thread_id=60007 <http://www.theserverside.com/discussions/thread.tss?thread_id=60007>It's just a RISC device with read/write barriers to support pauseless GC (this would be useful for any VM) and a native floating-point representation that aligns with Java's The idea is simple. Optimise to be the fastest device you can, with maybe a little support for a translation/compilation layer above you; don't optimise to try and embed that layer in hardware. It's not a new idea either, mainframes have been doing this kind of thing with microcode since the 70s ( http://en.wikipedia.org/wiki/Microcode) On 17 November 2010 10:50, Carl Jokl <[email protected]> wrote: > 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
