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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
