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

[Thomas Stuefe]

On Fri, 9 Oct 2020 17:11:23 GMT, Anton Kozlov <akozlov 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?



> > 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?

Are there any users of executable memory which cannot live with anonymous mapping on whatever address with small pages?
Does anyone need large pages or a specific wish address?

If not, maybe we really should introduce a (reserve|commit|uncommit|release)_executable_memory() at least temporarily,
as you suggested. At least that would be clear, and could provide a clear starting point for a new interface.

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

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