RFR: 8234930: Use MAP_JIT when allocating pages for code cache on macOS [v4]

[Anton Kozlov]

On Fri, 9 Oct 2020 06:05:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> GrowableArray maybe not the best choice here since e.g. it requires you to search twice on add. A better solution may
> be a specialized BST.

I assume amount of executable mappings to be small. Depends on if exec parameter available at reserve, it is either
only a single one for the CodeCache (see below) or plus several more for mappings with unknown mode (that were not
committed yet)

> IMHO too heavvy weight for a platform only change.
> If there are other uses for such a solution (managing memory regions, melting them together, splitting them maybe on
> remove)  we should not support setting and clearing exec on commit but only on a per-mapping base.

It is more simple when the whole mapping is executable or not. We don't need to split/merge on commit/uncommit then.
But we need do to something when os::release_memory is called on a submapping of a mapping with unknown status. Like on
AIX, uncommit is made https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2096. But here for
macOS, I'm trying to avoid any change of behavior for non-exec mappings.

If the exec parameter is provided for reserve (as it eventually would be), then we don't need splitting/merging at all.
This is what the latest patch is about. I haven't tested that thoroughly yet, but eventually it would be possible to
deduce correct exec values for os::reserve based on subsequent os::commit. If we make a step back, we have exec
parameter known for reserve and commit, I also pretty sure that it is possible to deduce that for any uncommit (which
was one of the initial concerns)

Let's agree on some plan how to attack the problem? I would like to distinguish the work toward MAP_JIT and improving
interface. Not sure what should come first. Are you still opposing to have exec parameter in
os::reserve/commit/uncommit and obligating callers to provide consistent exec values for each, at least at this phase?

I mean, eventually we will have a platform-dependent `handle_t` for mapping or equivalent. Like if we provide size of
the whole mapping (the context) for each commit_memory on AIX, we won't need to do the bookkeeping. What if os::commit
to take ReservedSpace and do something conservative when that is not provided?

-------------

PR: https://git.openjdk.java.net/jdk/pull/294