JDK-8079351 : Remove req_addr parameter from os::reserve_memory()
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • Submitted: 2015-05-05
  • Updated: 2021-01-07
  • Resolved: 2020-09-25
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.
Other
tbdResolved
Related Reports
Blocks :  
JDK-8245035 - Clean up os::split_reserved_memory()
Duplicate :  
JDK-8253638 - Cleanup os::reserve_memory and remove MAP_FIXED
Relates :  
JDK-8253638 - Cleanup os::reserve_memory and remove MAP_FIXED
Relates :  
JDK-8079449 - Improve os::attempt_reserve_memory_at() fallback coding on Linux, BSD, Solaris
Relates :  
JDK-8077276 - allocating heap with UseLargePages and HugeTLBFS may trash existing memory mappings (linux)
Description
The "wish address" parameter (aka "req_addr") for the os::reserve_memory() API is harmful and should be removed.

See discussion at: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-April/017823.html. 

In short, on mmap-based implementations (linux,bsd,solaris), calling os::reserve_memory() with a non-NULL wish address will trash existing mappings at that address, which is almost never what the programmer wants.

This is not a theoretical issue: programmers tend to confuse os::reserve_memory() with os::attempt_reserve_memory_at(). Unfortunately, often this does not lead to an immediate error, because address space is sparsely populated on 64bit. But if java vm is embedded into another application which already did a number of allocations, chance to trash existing mappings increases.

For all cases where one would want to use a wish address with os::reserve_memory, an alternative API exists. So, this parameter should be removed and code which relies on this parameter closely examined (e.g. see JDK-8077276).
Comments
That coding has metastased a bit since I last looked at it. The AllocateHeapAt feature led to a new parameter, a file descriptor, to be handed in. This is an unfortunate decision and could have been made in a cleaner way. We now have two variants of os::reserve_memory(), one which takes MEMFLAGS for NMT, one which takes a file descriptor for AllocateHeapAt. IMHO I think adding fd to reserve_memory() is a misuse of this API since reserving memory up to now meant anonymous mmap or the platform equivalent thereof. The os:: interface to abstract file mapping had been os::map_memory_to_file. Which is, curiously, still used under the hood. Disentangling this requires a bit more thinking than just removal of a parameter.
25-05-2020
No time for this currently :( I'm fine with closing it as wont fix.
22-02-2018