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.
7u121Fixed 8u112Fixed 9 b66Fixed
Related Reports
Relates :  
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.