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

[Thomas Stuefe]

On Sat, 5 Dec 2020 10:52:03 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> > I found this: https://stackoverflow.com/questions/7718964/how-can-i-force-macos-to-release-madv-freed-pages. One remark recommends MADV_FREE_REUSABLE to deal with the display problem; could that be a solution
> 
> I'd found MADV_FREE_REUSABLE as well. One problem is that it's barely documented. The only description from the vendor I could find was
> 
> ```
> #define MADV_FREE               5       /* pages unneeded, discard contents */
> #define MADV_ZERO_WIRED_PAGES   6       /* zero the wired pages that have not been unwired before the entry is deleted */
> #define MADV_FREE_REUSABLE      7       /* pages can be reused (by anyone) */
> #define MADV_FREE_REUSE         8       /* caller wants to reuse those pages */
> ```
> 
> The other problem, it cannot substitute mmap completely, see below.
> 
> > My only remaining question is: is there really an observable difference between replacing the mapping with mmap and calling madvice(MADV_FREE)? And if there is, does it matter in practice?
> 
> Yes, it is. For a sample program after uncommit implemented by different ways, mmap the only way to reduce occupied memory size in Activity Monitor (system GUI application user will likely look to).
> 

Okay, I see. Thanks for these tests, they are valuable. My one remaining doubt would be if the numbers were different in the face of memory pressure.

But I don't like to block this PR anymore, I caused enough work and discussions. So I am fine with the general thrust of the change:
- add exec to reserve and uncommit
- with the contract being that the exec parameter handed in with commit and uncommit has to match the one used with reserve.
Maybe we can have future improvements with these interfaces and reduce the complexity again (e.g. having an opaque handle structure holding mapping creation information). 

Is the current version review-worthy?

Thanks a lot for your patience,

..Thomas

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

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