Questions about java heap allocation and memory management

[Thomas Stüfe]

Hi everyone,

I have some questions about the allocation of the java heap.

The reason for these questions is that we are working at our (SAP JVM) AIX
port and right now we are thinking of reimplementing our java heap
allocation. This would then find its way into the OpenJDK AIX port.

Our initial implementation was very different from the way all other
platforms implement the heap allocation, due to some AIX specialities. This
difference between our code base and the OpenJDK hurts us continuously, so
now we are looking for a way to reimplement it closer to the OpenJDK. For
that I am investigating other platform implementations, especially some
corner cases I do not understand.

My questions:

1)

Large page mode with compressed oops, Windows and Linux:
- when large pages are active on Linux, sysV shm is used with the
SHM_HUGETLB flag. (ignoring for now the -XX:+UseHugeTLBFS mode).
- large pages on windows are implemented using VirtualAlloc() with
MEM_LARGE_PAGES
- Now, if compressed oops mode is active and we run in heap based mode
(high address range), we attempt to protect the heap base zone (that first
page needed for implicit nullchecks, ReservedSpace::no_access_prefix).

My question is, does this combination work and get tested in reality? On
Windows, VirtualProtect() will not work on large pages - at least it does
not work on my machine. On Linux, I do not know for certain, but Posix
states that mprotect can only be used on mmap'ed memory.


2)

os::split_reserved_memory()

At various places in the heap allocation ReservedSpace objects are split
into two entities; os::split_reserved_memory() is called.

I guess this is to deal with cases where the memory is one entity, e.g.
VirtualAlloc() on windows and sysV shared mem on Unix? As opposed to
mmap(), which can be released page-wise.

On Unix platforms, this is a noop. I guess the assumption is that the
memory was allocated by mmap(), so not splitting is needed. But what
happens if the original memory was allocated using sys V shm, e.g. via
os::reserve_memory_special()? In that case the first ReservedSpace would
quietly inherit the ownership of the whole area, including the second
ReservedSpace, and release both halves.

On Windows, this function releases the whole memory and re-allocates it in
the same address space in two chunks. This sounds dangerous, because
someone else in the process may allocate concurrently and populate that
address space. Am I overlooking something, does the code deal with this
somehow?


Thanks a lot!


Kind Regards, Thomas