JDK-6525802 : server compiler should support certain reflective and data motion intrinsics
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2007-02-16
  • Updated: 2013-11-01
  • Resolved: 2007-05-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u4Fixed 7Fixed hs10Fixed
Related Reports
Relates :  
JDK-6569243 - Crash in javac while building JDK7, after sync with 7.0-b14
Relates :  
JDK-6614036 - REGRESSION: Java server x86 VM intermittently crash with SIGSEGV (0xb)
Relates :  
JDK-6565543 - Unsafe.java changes corresponding to 6525802
Relates :  
JDK-4463011 - (bf) View-buffer bulk get/put operations are slow
Relates :  
JDK-6428387 - array clone() much slower than Arrays.copyOf
Description
The following functions should be intrinsics, because they can be optimized, their native performance is poor, and they are important either to known benchmarks or common uses of reflection.

Class.getComponentType, getSuperclass, isArray, isInterface, isPrimitive
Object.clone
Unsafe.copyMemory
Arrays.copyOf, copyOfRange
Array.getLength, newArray
Comments
EVALUATION Yes. See Suggested Fix for a patch to Unsafe.java which provides new addressing modes for copyMemory and setMemory. After these intrinsics are added to Unsafe, there may be a number of native methods in J2SE which should be coded in terms of compiler intrinsics (such as Unsafe.copyMemory and Integer.reverseBytes), so that the compiler and runtime system can properly optimize them. See, for example, java.nio.Bits.copyFromByteArray. The bug 4463011 talks about the optimization of NIO under the assumption that Unsafe.copyMemory would not be available. Now it is.
21-04-2007
SUGGESTED FIX The following patch should be applied to J2SE after this VM fix is promoted (1.7 b13). --- Unsafe.java.orig 2007-04-04 13:21:09.840035000 -0700 +++ Unsafe.java 2007-04-21 15:38:31.186254000 -0700 @@ -499,15 +481,63 @@ /** * Sets all bytes in a given block of memory to a fixed value * (usually zero). + * + * <p>This method determines a block's base address by means of two parameters, + * and so it provides (in effect) a <em>double-register</em> addressing mode, + * as discussed in {@link #getInt(Object,long)}. When the object reference is null, + * the offset supplies an absolute base address. + * + * <p>The stores are in coherent (atomic) units of a size determined + * by the address and length parameters. If the effective address and + * length are all even modulo 8, the stores take place in 'long' units. + * If the effective address and length are (resp.) even modulo 4 or 2, + * the stores take place in units of 'int' or 'short'. + * + * @since 1.7 + */ + public native void setMemory(Object o, long offset, long bytes, byte value); + + /** + * Sets all bytes in a given block of memory to a fixed value + * (usually zero). This provides a <em>single-register</em> addressing mode, + * as discussed in {@link #getInt(Object,long)}. + * + * <p>Equivalent to <code>setMemory(null, address, bytes, value)</code>. */ - public native void setMemory(long address, long bytes, byte value); + public void setMemory(long address, long bytes, byte value) { + setMemory(null, address, bytes, value); + } /** * Sets all bytes in a given block of memory to a copy of another * block. + * + * <p>This method determines each block's base address by means of two parameters, + * and so it provides (in effect) a <em>double-register</em> addressing mode, + * as discussed in {@link #getInt(Object,long)}. When the object reference is null, + * the offset supplies an absolute base address. + * + * <p>The transfers are in coherent (atomic) units of a size determined + * by the address and length parameters. If the effective addresses and + * length are all even modulo 8, the transfer takes place in 'long' units. + * If the effective addresses and length are (resp.) even modulo 4 or 2, + * the transfer takes place in units of 'int' or 'short'. + * + * @since 1.7 */ - public native void copyMemory(long srcAddress, long destAddress, + public native void copyMemory(Object srcBase, long srcOffset, + Object destBase, long destOffset, long bytes); + /** + * Sets all bytes in a given block of memory to a copy of another + * block. This provides a <em>single-register</em> addressing mode, + * as discussed in {@link #getInt(Object,long)}. + * + * Equivalent to <code>copyMemory(null, srcAddress, null, destAddress, bytes)</code>. + */ + public void copyMemory(long srcAddress, long destAddress, long bytes) { + copyMemory(null, srcAddress, null, destAddress, bytes); + } /** * Disposes of a block of native memory, as obtained from {@link
21-04-2007
SUGGESTED FIX Job ID: 20070413103655.jrose.dolphin-intrinsics Original workspace: foundation:/export/jrose/ws/dolphin-intrinsics Submitter: jrose Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070413103655.jrose.dolphin-intrinsics/ Webrev: http://prt-web.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/c2_baseline/2007/20070413103655.jrose.dolphin-intrinsics/workspace/webrevs/webrev-2007.04.13/index.html Fixed 6525802: server compiler should support certain reflective and data motion intrinsics Fixed 6428387: array clone() much slower than Arrays.copyOf Reviewed by: Vladimir, Tom (partial) Fix verified (y/n): y Testing: - Intrinsics produce correct, faster, code and pass PRT. - Intrinsic tests and runThese with +StressReflectiveCode. - ArrayCopyMicroBenchmark shows consistent performance across copy idioms - CTW of /net/vmsqe.sfbay/export/backup/testbase/CompileTheWorld/jarfiles/* CTW testing exercised over 100,000 occurrences of the intrinsics. Implemented intrinsics not exercised by CTW were _attemptUpdate, _copyMemory, _dlog10, reverseBytes_[il], and some (not all) of the unsafe accessors (named like _getX, _putX, and _prefetchX).
21-04-2007