JDK-8077276 : allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Type: Bug
- Component: hotspot
- Sub-Component: gc
- Affected Version: 9
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- OS: linux
- Submitted: 2015-04-08
- Updated: 2016-10-13
- Resolved: 2015-05-05
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.
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 7 | JDK 8 | JDK 9 |
|---|---|---|
| 7u121Fixed | 8u112Fixed  |
9 b66Fixed |
Related Reports
|
Relates :
|
Description
Code review showed that on Linux, if heap is allocated via reserve_memory_special_huge_tlbfs_mixed(), mmap(addr, MAP_FIXED) gets called to establish heap memory which will trash existing mappings which happen to be located in that area. I could also reproduce this experimentally. The error is that reserve_memory_special_huge_tlbfs_mixed() calls os::reserve_memory() with a requested_addr != null to establish an initial memory mapping where none existed before. It might be smart to get rid of the requested_addr parameter to os::reserve_memory altogether, see http://comments.gmane.org/gmane.comp.java.openjdk.hotspot.devel/18049. I don't think there is a way this parameter can be used correctly in this API.