-
Type:
Enhancement
-
Resolution: Fixed
-
Priority:
P4
-
Affects Version/s: None
-
Component/s: hotspot
-
b18
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8281194 | 15.0.7 | Yuri Nesterenko | P4 | Resolved | Fixed | b02 |
I propose that we change the paramter order from:
os::attempt_reserve_memory_at(size, addr, <extra params>)
to:
os::attempt_reserve_memory_at(addr, size, <extra params>)
The motivation is that it's simply awkward to have attempt_reserve_memory_at use the opposite order of most other memory range APIs.
Examples of APIs using the order addr, size:
1) void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
2) PVOID VirtualAlloc2(..., BaseAddress, Size, ...)
3) ReservedMemoryRegion(address base, size_t size)
4) MemRegion(HeapWord* start, size_t word_size)
5) ReservedSpace(char* base, size_t size
6) commit_memory(char* addr, size_t bytes, bool executable)
os::attempt_reserve_memory_at(size, addr, <extra params>)
to:
os::attempt_reserve_memory_at(addr, size, <extra params>)
The motivation is that it's simply awkward to have attempt_reserve_memory_at use the opposite order of most other memory range APIs.
Examples of APIs using the order addr, size:
1) void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
2) PVOID VirtualAlloc2(..., BaseAddress, Size, ...)
3) ReservedMemoryRegion(address base, size_t size)
4) MemRegion(HeapWord* start, size_t word_size)
5) ReservedSpace(char* base, size_t size
6) commit_memory(char* addr, size_t bytes, bool executable)