JDK-8253638 : Cleanup os::reserve_memory and remove MAP_FIXED
- Type: Enhancement
- Component: hotspot
- Sub-Component: runtime
- Priority: P4
- Status: Resolved
- Resolution: Fixed
- Submitted: 2020-09-25
- Updated: 2024-10-17
- Resolved: 2020-09-28
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 15 | JDK 16 |
|---|---|
| 15.0.7Fixed | 16 b18Fixed  |
Related Reports
|
Duplicate :
|
|
|
Relates :
|
Description
There's a code path through os::reserve_memory that uses MAP_FIXED. This path is used if a requested address is given. It's very dangerous to use MAP_FIXED, since it causes preexisting mappings to be replaced. Mac AARCH64 also can't use it in conjunction with MAP_JIT. I started to split os::reserve_memory into two functions; one that doesn't care about were the memory is mapped, and another (os::reserve_memory_at) that uses the dangerous MAP_FIXED flag. However, I noticed that it's only windows code that actually use os::reserve_memory with a requested address. All other usages have been cleaned out and replaced with os::attempt_reserve_memory. And on windows os::attempt_reserve_memory uses os::reserve_memory with comments that it's safe because it only "attempts" to place the mapping. So, this patch: 1) Removes the forcefully reserving of memory 2) Changes the windows code to call the attempt_reserve_memory verison, that it actually did anyway. 3) There's also some unification and split done to handle MEMFLAGS and fds. This part needs followup cleanups (IMHO).
Comments
|