JDK-8253649 : Potential bug in os::split_reserved_memory on windows
- Type: Bug
- Component: hotspot
- Sub-Component: runtime
- Affected Version: 16
- Priority: P4
- Status: Resolved
- Resolution: Duplicate
- Submitted: 2020-09-25
- Updated: 2022-09-14
- Resolved: 2021-01-08
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 17 |
|---|
17Resolved  |
Related Reports
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
|
|
Relates :
|
Description
The code looks like this on windows: release_memory(base, size); attempt_reserve_memory_at(split, base); attempt_reserve_memory_at(size - split, split_address); After the release and before the re-reservations, another thread could reserve that memory. Investigate the effects of this. We've had similar bugs in the past, where memory are temporarily unmapped and non-JVM threads reserves memory in the requested area.
Comments
|