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

[Francis ANDRE]

>>  	byte[]	user;
>> 	int value = 32;
>>
>> 	user = new byte[9];
>> 	user[5] = (byte)((value & 0xFF000000) >> 24);
>> 	user[6] = (byte)((value & 0x00FF0000) >> 16);
>> 	user[7] = (byte)((value & 0x0000FF00) >> 8);
>> 	user[8] = (byte)((value & 0x000000FF) >> 0);
>
> This does lead to big bytecodes.  You can compress the bytecodes by
> using a subroutine:
> 	class PackedArray { ...
> 	  int getInt(byte[] array, int offset) { ... }
> 	}
>
Yes, I am already using a subroutine that LOAD & STORE integer of 1, 2  
and 4 bytes long with the same signature as yours(byte[], offset). But  
I wanted to emphasis on the performance issue without prompting the  
subroutines.


> Corresponding code:
>>    0:   bipush  9
>>    2:   newarray byte
>>    4:   astore_1
>>    5:   aload_1
>>    6:   iconst_5
>>    7:   bipush  32
>>    9:   invokestatic #PackedArray.setInt([BII)V
>
>> 2/ Proposal
>>  My proposal is to relax the type array constraint on all xALOAD and
>> all xASTORE JVM instructions
> 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.

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

>
> Packed data structures are an interesting pain point.  Perhaps they
> need not be packed?  Could a Cobol implementation use native JVM
> packing order (mapping Cobol structs to natural JVM instances), but
> providing on-demand views which simulate the needed byte order, when
> required by aliasing?  I'm guessing that most Cobol programs would not
> rely on byte ordering, most of the time.
>
The problem for packed/zoned data is identical as for integer: just  
inefficiency
and performance.

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.

More on packed/zoned cobol data in a following mail...


Francis