JDK-8253851 : Issues with os:reserve_memory_aligned on Posix
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2020-09-30
  • Updated: 2023-10-05
  • Resolved: 2023-10-05
Related Reports
Relates :  
Description
JEP 316 was added to reserve the heap on a file device. It added an file descriptor argument to calls like os::reserve_memory and friends.

There are a number of issues with this:
- in os::reserve_memory_aligned, Posix: mmap is called to reserve, then the generic os::release_memory is called to release parts of it. Or all in case of an error. 
- Same problem also in reserve_mmapped_memory() in the same file
- Comment states that mappings established with a file descriptor cannot be partially unmapped. Not sure if that is true. If it is untrue, that coding can be simplified a lot.


Comments
Reclosing as "Not an Issue" instead of Resolving as...
05-10-2023

Hi [~azafari], thanks for looking into this. My concern with the original implementation (before JDK-8255254) was that it assumed that os::reserve and os::release are implemented using mmap, which may not be the case (AIX for instance uses system V shared memory). That may lead to mixing APIs (reserve with mmap, attempt to release with shmat). But I see that JDK-8255254 cleaned that part up, so I think we are good here. This issue can be closed.
04-10-2023

[~stuefe], some more explanations are needed. The call hierarchy is os::reserve_memory_aligned() --> os::reserve_memory() --> pd_reserve_memory() different versions for Linux (os_linux.cpp) and Windows (os_windows.cpp) and for releasing memory os::release_memory() --> pd_release_memory() different versions for Linux and Windows. So, although the generic os:xxx_memory() functions are called they will be redirected to the appropriate pd_xxx_memory(). So, what is your point here? The same for reserve_mmaped_memory(). Which comments in the code are you referring to?
27-09-2023