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.
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.
- relates to
-
JDK-8010722 assert: failed: heap size is too big for compressed oops
- Closed
-
JDK-8024669 Native OOME when allocating after changes to maximum heap supporting Coops sizing on sparcv9
- Closed