A question about bytecodes

[John Rose]

On Jan 9, 2009, at 1:27 PM, Tom Rodriguez wrote:

> One thing I might mention is that there's another approach to  
> adding unsigned which is to do in the form of an API that's  
> expected to be intrinsified by the JVM.  The performance of this  
> would/could be exactly the same as a bytecoded version without  
> requiring a change to the JVM specification for adoption, which I  
> think is a largely insurmountable barrier.

That's the material point.  Let's be clear:  There is almost *never*  
a reason to add a new bytecode, because an intrinsic method will  
almost *always* work just as well.

Any change to bytecodes requires lots of VM and tool changes by every  
vendor, which means it had better be really important and with no  
feasible alternative (such as intrinsic methods).  In particular,  
adding lots of new bytecodes to express something as simple as  
unsigned operations is a waste of limited bytecode coding space  
(unless a system of prefixes were invented).  Note that compilers  
tend to optimize expressions like myByteArray[i] & 0xFF into unsigned  
loads, and packaging this into an intrinsic method would add  
predicability of compilation (if anybody cares), and the case is not  
frequent enough to warrant shaving a few bytes off the instruction  
format.

For example, I work on JSR 292, which is adding one bytecode for  
invokedynamic; every other operation (and it's a much richer API than  
unsigned arithmetic) can be expressed in terms of existing  
bytecodes.  The invokedynamic operation cannot be emulated in  
existing bytecodes without an order of magnitude or more of size and  
speed degradation, and it occurs (will occur) frequently in certain  
common types of user code (byte-compiled dynamic languages).  Even  
so, it took 10 years to introduce it.

Stephen, if you want a project that really does appear to require new  
bytecodes, but which nobody has attempted yet, I recommend you look  
at this one:
   http://blogs.sun.com/jrose/entry/tuples_in_the_vm

Best wishes,
-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090109/5e4c6ea9/attachment.html