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.
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.
- duplicates
-
JDK-8255917 runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"
- Resolved
- relates to
-
JDK-8255978 [windows] os::release_memory may not release the full range
- Closed
-
JDK-8257040 [posix] os::split_reserved_memory will not work as expected on SysV shm
- Closed
-
JDK-8245035 Clean up os::split_reserved_memory()
- Resolved
-
JDK-8256079 Heterogeneous Heap may fail silently on Windows
- Closed
-
JDK-8256729 [windows] runtime/cds/SharedBaseAddress.java: assert on split_reserved_memory
- Closed
(1 relates to)