Wednesday Nov 08, 2006
Wednesday Nov 08, 2006
Greetings one and all. You're probably here because Gilad kindly pointed the way. His contributions to Sun span two millenia and have been more immense than most people know; the Java Language and VM Specifications set the bar for modern platform documentation. It is an honour to follow in his footsteps and I wish him the best of luck with his new and dynamic endeavours.
I plan to blog about interpretation of the JLS and JVMS; design issues on JSRs that I'm involved with; and proposals for language features both old and new. I also hope to bring the JLS and JVMS into the blogging age by publishing clarifications and corrections as tagged entries.
So with Java SE 6 emerging and the lifecycle for SE 7 starting - and with the debate about Java's place in the world reaching fever pitch - it will surely be the most interesting of times.
Posted by Dmitri Trembovetski on November 08, 2006 at 10:40 AM PST #
Posted by Danny Coward on November 08, 2006 at 02:13 PM PST #
Posted by 193.50.159.2 on November 09, 2006 at 02:29 AM PST #
Posted by Bas de Bakker on November 16, 2006 at 12:56 AM PST #
I've been thinking about this for a couple of days and since you're now responsible for the JVMS, let me pitch this to you:
How about a new bytecode specification?
There is a proposal to add a new bytecode to the existing spec (http://jcp.org/en/jsr/detail?id=292), that would be solved.
It would allow to add reified generics support at the bytecode level (http://gafter.blogspot.com/2006/11/reified-generics-for-java.html). There was a proposal to add two new bytecodes when generics for java was first discussed, I don't have the url right now though.
It would allow to add unsigned data types at the bytecode level, as well as tail-recursion support.
It would allow to remove the bytecodes that have become deprecated in the new split verifier support (http://jcp.org/en/jsr/detail?id=202).
It could also allow removal of the superfluous _x instructions (for example iload_2). These were introduced to reduce the memory size. However, most class files are compressed anyway as a jar/new packed meta-package format and it might actually be worthwhile to replace those compressed instructions by non-compressed ones and leave the compression to the compressor - i.e. this could reduce the size.
It would allow stricter typing at the bytecode level (e.g. for boolean).
It would allow to remove the (arbitrary, and IMHO ultimately dangerous) 32/64 bit distinction for local variables and stack, which in turn would simplify the stack manipulation operations. That distinction was made to enable simpler implementation of an interpreter on 32 bit architectures. To reenable this, one could add a 'precompiled' mode where stack-manipulation/local variables addresses are resolved ahead of time; this could be done with a small additional reserved instruction block.
I envision dividing the bytecode into instruction blocks, one for ALU instructions, one for conversion instructions, one for control-flow instructions, one for legacy-support (32/64 bit precompilation).
Furthermore, if done right, this new bytecode would be conversion-compatible with the old one - that is, the old one could be easily converted to the new, even behind the scenes, for legacy support. The new one could be converted to the old with a few exceptions: invokedynamic and the reified generics instructions. It would thus be conversion-compatible in both directions with all current java compilers and tools.
This change would make java much more interesting as a target for languages other than java. It would also pave the way for reified generics and unsigned data types.
Cheers, Ulf
Posted by Ulf Ochsenfahrt on February 01, 2007 at 03:11 PM PST #