Da Vinci MLVM: Interest for an very old language running on an extended JVM
John.Rose at Sun.COM
Wed Apr 23 00:30:37 PDT 2008
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
> 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
> while using a relaxed identical opcode will work also in
> interpreted mode
> (which is a important point for the debugging tool to align the
> 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
> 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):
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
> 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
> More on packed/zoned cobol data in a following mail...
More information about the mlvm-dev