JDK-4861898 : -XX:+AggressiveHeap broken in build 1.4.2_22 for Windows/IA64
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: itanium
  • Submitted: 2003-05-09
  • Updated: 2003-06-24
  • Resolved: 2003-06-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.
Other
1.4.2_08Fixed
Related Reports
Relates :  
JDK-4831461 - JNI GetEnv() race with ThreadLocalStorage::set_thread() guarantee
Description
We've recently noticed a problem with -XX:+AggressiveHeap.  When we run SPECjbb,
even with a simple command line:

	java -XX:+AggressiveHeap -Xmn2000m -Xms6000m -Xmx6000m -cp ... spec
classpath etc. ...

the JVM processes for ~10 seconds and then returns to the Windows Command Prompt
-- no errors reported.

** This problem started with build 22 **

Any suggestions for tracing options to determine where this problem might be?
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger FIXED IN: tiger INTEGRATED IN: tiger tiger-b10
14-06-2004
EVALUATION Reproducible on Unisys' MP systems only. We can't reproduce it on the 2-way systems we have. Unisys's report seems to imply that the stack-allocated variables lpProcessAffinityMask and lpSystemAffinityMask, when they're declared to be DWORD's, have been allocated by the C++ compiler on 4-byte boundaries, thus provoking a segv when GetProcessAffinityMask tries to write them as if they were UINT_PTR's, which must be aligned on an 8-byte boundary. But if this were so, *every* call to GetProcessAffinityMask would provoke a segv. So we ought to be seeing this problem on our machines, but we don't. I suspect we're running an OS that silently fixes up misaligned data accesses, and Unisys isn't. Also, it looks like our implementation of os::active_processor_count is flawed in a further way, since GetProcessAffinityMask returns bit vectors that can be up to os::processor_count long, whereas a DWORD is limited to 32 bits and a UINT_PTR 64. The fix is to only call GetProcessAffinityMask if the total processor count is <= bitsize(UINT_PTR). ###@###.### 2003-06-16
16-06-2003