A question about bytecodes

[John Rose]

On Jan 10, 2009, at 8:49 AM, Francis ANDRE wrote:

> There is a good reason to have new bytecodes to support additional  
> data type that the current JVM does not support.

That is the reason I proposed the tuples extension, which uses a few  
extra bytecodes in order to introduce an unlimited set of new  
"inline" or "struct" types.

But this reasoning does not motivate new bytecodes for unsigned, or  
for any other single type.  Rather, it motivates a (nominal) tuple  
mechanism, allowing unsigned (and complex and decimal and rational  
and unicode pair and...) to be represented using a more general tuple  
mechanism.

(A primitive type I have sometimes felt was missing is T_VECTOR, a  
128-bit integer.  Of course, these will soon become 256 bits.  But  
either of these types could be readily represented as a tuple of  
T_LONG components.)

> Using intrinsic method forces to allocate working variable on the  
> head while they are absolutely *temporary* with the scope limited  
> to the expression statement

It would be wrong to say that putting things in the heap is always  
slower than putting them on the stack.  The escape analysis  
optimization (now present in JDK7) scalarizes objects (turns them  
into tuples) in many common cases, if the optimizer can prove that  
the object is only referred to locally.


In particular, the above statement is not always true, because escape  
analysis works on such working variables.

The only way to tell for certain whether the optimizer has performed  
escape analysis (or any other desired optimization) is to examine the  
assembly code.  See:
   http://wikis.sun.com/display/HotSpotInternals/PrintAssembly

As I think I said earlier, making a common idiom into an intrinsic  
increases the chance that the programmer will code the intended  
operation in a manner that the optimizer will recognize.

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-dev/attachments/20090110/a14a7fbd/attachment.html