On Wed, Nov 17, 2010 at 9:50 PM, 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. > > All the investment in the current bytecode and class files would be lost. Some work would need to be done to cross compile the original source or transform them with a tool to the new system. Not exactly a drop in replacement... > 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. > > One of java's strenghts is the bytecode is an abstraction over the native cpu which means the jit can do smart things depending on which generation of a cpu it gets. This argument is actually completely wrong. Generally GPUs have not been used for general puirpose programming tasks, they are typically used for stuff thats naturally well suited to parallel execution like processing an image which is very different from the programs most of us write today and tomorrow. If you can give an example of a system that uses GPUs instead of a regular cpu i would be very interested. From my part of world and limited reading of the net i have yeet to hear of a system without a core cpu and entirely powered by gpus. Even the old games machines of yesteryear where all this started all have a core cpu and specialised helpers. The Amiga had DMA which could do stuff faster than the cpu but nobody ever wrote their programs entirely as a copper list w/out any 68000. The same goes for SNES, MD, PSX, PS2 etc. > 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. > Exactly so youve just jumped back to emulation of the bytecode, classloading and more. Nothing is a first class citizen which means everytjhing just became a lot slower. > > 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. > > Yes Jazelle only executes on bytecode set not multiple. What happens if one wishes to run dotnet and java on the same host at the same time ? So what haappened to Jazelle, if it was such a good idea where did it go ? > -- > 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. > > -- mP -- 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.
