A question about bytecodes
John.Rose at Sun.COM
Sat Jan 10 10:55:27 PST 2009
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
(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
> 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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-dev