JDK-6999491 : non-zero COOPs are used when they should not
Type:Bug
Component:hotspot
Sub-Component:runtime
Affected Version:hs19,hs20
Priority:P3
Status:Closed
Resolution:Fixed
OS:generic
CPU:generic
Submitted:2010-11-12
Updated:2012-10-01
Resolved:2011-04-23
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.
Running with "-Xmx35g -XX:HeapBaseMinAddress=32g" leads to COOPs used.
However, virtual space address limit exceeds 32g, so no COOPs should be used.
ObjectAlignmentInBytes is equal to 8 in this case.
PUBLIC COMMENTS
Regression introduced by fix for 6984368 bug. The expression in max_heap_for_compressed_oops() produces incorrect result when HeapBaseMinAddress > OopEncodingHeapMax.
HeapBaseMinAddress should be used only for a default heap size calculation.
Added heap size to PrintCompressedOopsMode output.
EVALUATION
Regression introduced by fix for next bug
6984368: Large default heap size does not allow to use zero based compressed oops
The next expression result is negative with such options and it will return huge unsigned value
inline uintx max_heap_for_compressed_oops() {
// Heap should be above HeapBaseMinAddress to get zero based compressed oops.
LP64_ONLY(return OopEncodingHeapMax - MaxPermSize - os::vm_page_size() - HeapBaseMinAddress);
so the next condition will be always true
if (MaxHeapSize <= max_heap_for_compressed_oops()) {