A question about bytecodes

[Francis ANDRE]

John Rose a écrit :
> 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.
There is a good reason to have new bytecodes to support additional data 
type that the current JVM does not support.

While intrinsic method are ok whenthe  extra additional operation is 
needed to be performed on existing JVM data type, adding a new data type 
like PackedDecimal for example allows to have local temporary variable 
of this new type on the stack for the evaluation of expression. Using 
intrinsic method forces to allocate working variable on the head while 
they are absolutely *temporary* with the scope limited to the expression 
statement. Moreover, using temporary on the stack never pollute the heap 
and thus one gain in performance by avoiding unnecessary GC cycles!


>
> 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