JDK-8024925 : Ergonomics do not correctly calculate the maximum heap size to get zero based oops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2013-09-17
  • Updated: 2015-11-09
  • Resolved: 2015-11-09
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 9
9Resolved
Related Reports
Relates :  
JDK-8024669 - Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9
Relates :  
JDK-8010722 - assert: failed: heap size is too big for compressed oops
Description
Ergonomics calculation to get the maximum heap size to get zero based compressed oops is wrong.

The current calculation is as follows:

OopEncodingMax - HeapBaseMinAddress - align_up(vm_page_size, maximum conservative heap size)

However in case of zero based oops, the space reserved due to HeapBaseMinAddress already contains the zero page, so actually the calculation should be

OopEncodingMax - MAX2(HeapBaseMinAddress, align_up(vm_page_size, maximum conservative heap size))

Further, when actually trying to reserve this maximum heap size for zero based oops, during quick checking it seems that most OSes fail to do so, always returning heap based compressed oops.
Check whether this is an OS issue (i.e. the OS never allows zero heap based oops) or not.
Comments
I don't see this issue.
23-10-2015
All this code has changed so I'm not sure if this is an issue anymore. Or rather, I don't see what the issue is. The calculation (while somewhat complex) looks correct to me.
28-04-2015