Da Vinci MLVM: Interest for an very old language running on an extended JVM

[John Rose]

On Apr 18, 2008, at 3:34 AM, Francis ANDRE wrote:

>> The performance story is better too, since whether it's a bytecode or
>> subroutine, you may have to wait for the compiler team to cook up the
>> desired optimizations, but it's usually a shorter wait for the
>> subroutine.  And now that we are open source, you can submit your own
>> patch for the desired compiler intrinsic.  That will always be easier
>> than submitting a patch for a new bytecode.
>
> I am not requesting new opcodes but just relaxing the array type  
> contraint
> of the already existing xALOAD & xASTORE when the VM run a Cobol or  
> C class.

It really amounts to the same complexity as a new opcode, since every  
tool or JVM phase that looks at opcodes may need to know the new usages.

(And in this case, we probably already have intrinsic methods which  
compile to the code you want.  See below.)

> Moreover, the optimization you mention works only with the JIT  
> generation
> while using a relaxed identical opcode will work also in  
> interpreted mode
> (which is a important point for the debugging tool to align the  
> generated
> code with the original source while getting an optimal performance).

It seems to me just as easy to align source code to a BCI which  
contains an invokestatic as a BCI which contains an iaload.

> The problem for packed/zoned data is identical as for integer: just  
> inefficiency
> and performance.

With very few exceptions, the fastest way to get performance on some  
operation is first to name it (as a method), then have the compiler  
treat it as an intrinsic.  Here is a list of all the intrinsics in  
HotSpot (start 50% down around line 416):
   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/8b0b3490194f/src/ 
share/vm/classfile/vmSymbols.hpp

Some of these have in the past been requested as special bytecodes,  
but they all work better as methods.

By the way, aligned (or on Intel unaligned little-endian) accesses  
can be performed in VM-specific code by operations like  
Unsafe.getInt.  For example, those are used for fast type-punning  
access in NIO buffers.  A NIO byte buffer can be punned (in a type- 
safe way) with an int buffer, to get the kind of accesses you want.   
It is implemented with intrinsics in Unsafe.  There is no need for  
special bytecodes.

> As for integer, there is no problem for getting the rigth semantic  
> with a metadata of the packed/zoned data and subroutines with  
> signature like (byte[], offset, precision, scale and sign) but the  
> assignement/retrieval of value is done on a byte to byte basis  
> which is highly inefficient while a interpreted/compiled opcode  
> could do it efficiently.

And so also do compiled intrinsics provide a way to do these things  
efficiently.  Think of bytecodes as low-level IR, which is very  
expensive to extend, and intrinsic method calls as a higher-level  
extensible part of the IR, which is it easy to extend compatibly.

If there really is a need for interpreted performance (which is in  
practice very rarely demonstrated) the interpreter has ways to treat  
methods as intrinsics also.  This is almost never done.  See enum  
MethodKind in:
   http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/8b0b3490194f/src/ 
share/vm/interpreter/abstractInterpreter.hpp

> More on packed/zoned cobol data in a following mail...
Thank you!

-- John