JDK-4659977 : Allocate buffers for arrays at 8-byte aligned addresses
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: solaris_2.6
  • CPU: sparc
  • Submitted: 2002-03-29
  • Updated: 2013-11-01
  • Resolved: 2003-06-16
Related Reports
Relates :  
JDK-6661301 - 128-bit alignment of arrays for JNI SSE
Description
I am not sure if native_interface is the correct subcategory for this issue.
If not, please reassign it.

As you know, for better performance, 8-byte aligned buffers are desired,
especially when SIMD-style instructions like the VIS on UltraSPARC are
used.  The Get<PrimitiveType>ArrayElements functions seem to be able to
copy arrays to native buffers starting from 8-byte aligned addresses all
the time, which is good.

It came to my notice that non-double arrays pinned by the JNI function
GetPrimitiveArrayCritical are always starting from addresses which are
not 8-byte aligned.  In fact, they are always starting from either ...4
or ...C.  I hope that the VM can be somewhat modified to allocate arrays
starting from 8-byte aligned addresses.

A test case, TestArray.java, is attached to this report.  The results
I got are as follows:

solarcell % run.csh
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)
------ i = 0 ------
bp = e243ee14, Get-isCopy = 0, Release-isCopy = 2
sp = e243f2ec, Get-isCopy = 0, Release-isCopy = 2
ip = e243fbc4, Get-isCopy = 0, Release-isCopy = 2
fp = e2440c9c, Get-isCopy = 0, Release-isCopy = 2
dp = e2441d78, Get-isCopy = 0, Release-isCopy = 2
------ i = 1 ------
bp = e2443f9c, Get-isCopy = 0, Release-isCopy = 2
sp = e24443ac, Get-isCopy = 0, Release-isCopy = 2
ip = e2444bbc, Get-isCopy = 0, Release-isCopy = 2
fp = e2445bcc, Get-isCopy = 0, Release-isCopy = 2
dp = e2446be0, Get-isCopy = 0, Release-isCopy = 2
------ i = 2 ------
bp = e2448d3c, Get-isCopy = 0, Release-isCopy = 2
sp = e244914c, Get-isCopy = 0, Release-isCopy = 2
ip = e244995c, Get-isCopy = 0, Release-isCopy = 2
fp = e244a96c, Get-isCopy = 0, Release-isCopy = 2
dp = e244b980, Get-isCopy = 0, Release-isCopy = 2
------ i = 3 ------
bp = e244dadc, Get-isCopy = 0, Release-isCopy = 2
sp = e244deec, Get-isCopy = 0, Release-isCopy = 2
ip = e244e6fc, Get-isCopy = 0, Release-isCopy = 2
fp = e244f70c, Get-isCopy = 0, Release-isCopy = 2
dp = e2450720, Get-isCopy = 0, Release-isCopy = 2
------ i = 4 ------
bp = e245287c, Get-isCopy = 0, Release-isCopy = 2
sp = e2452c8c, Get-isCopy = 0, Release-isCopy = 2
ip = e245349c, Get-isCopy = 0, Release-isCopy = 2
fp = e24544ac, Get-isCopy = 0, Release-isCopy = 2
dp = e24554c0, Get-isCopy = 0, Release-isCopy = 2
Comments
WORK AROUND Peter Kessler suggests: The user could always make sure that their array was one element longer than they needed, and just waste the zeroth element of the array. That is, they could take responsibility for the alignment themselves. Then their code would work on any JVM, and not depend on the JVM to provide the service they need. ###@###.### 2003-06-16
16-06-2003
EVALUATION GetPrimitiveArrayCritical returns the address of the array element body in the java heap. Array objects are allocated on 8-byte boundaries. The header is 3 pointers long, 12 bytes for the 32-bit vm, 24 for the 64-bit one. Non-double/long array elements are allocated abutting the header, while double/long elements are aligned on the next 8-byte boundary. In 32-bit vm's, that means the first element of non-double/long is always 4-byte aligned, while in 64-bit vm's it's 8-byte aligned. We may change to 8-byte alignment in the 32-bit vm's in a future release. If an array is short-lived, doing so probably doesn't cost anything, since it will be collected quickly. Most byte and short arrays (strings) are short- lived. Aligning int array elements doesn't cost any memory for even numbers of elements, and 4 bytes for odd. If most int arrays have an even number of elements, we win at no cost. If the number of elements is random, we waste an average of 2 bytes per array. ###@###.### 2003-06-13 See workaround for a solution. Since there's a workaround, and since the performance effect in general is unknown, I'm closing this bug as 'will not fix'. If the workaround is unusable for some reason, please reopen the bug. ###@###.### 2003-06-16
16-06-2003