Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8082760 | emb-9 | Thomas Stuefe | P4 | Resolved | Fixed | team |
JDK-8163630 | 8u121 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
JDK-8157451 | 8u112 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
JDK-8167737 | emb-8u121 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
JDK-8157822 | 7u121 | Thomas Stuefe | P4 | Resolved | Fixed | b01 |
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.
- backported by
-
JDK-8082760 allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Resolved
-
JDK-8157451 allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Resolved
-
JDK-8157822 allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Resolved
-
JDK-8163630 allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Resolved
-
JDK-8167737 allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
- Resolved
- relates to
-
JDK-8079351 Remove req_addr parameter from os::reserve_memory()
- Closed