RFR: 8224817: Implementation of JEP 364: ZGC on macOS

[Erik Osterlund]

Hi Thomas,

Sure I can file an RFE. For anonymous mmaped memory, a seemingly undocumented feature is that you can pass in superpage flags for the mach VM system via the file descriptor parameter. Anyway, I will detail it in the RFE.

/Erik

> On 24 Oct 2019, at 17:57, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi,
> 
>> On 24.10.19 17:47, Per Liden wrote:
>> Hi,
>>> On 10/24/19 12:38 PM, erik.osterlund at oracle.com wrote:
>>> Hi,
>>> 
>>> Now that some curling has been performed, paving way for this patch:
>>> 
>>>      8229027: Improve how JNIHandleBlock::oops_do distinguishes oops from non-oops
>>>      8229278: Improve hs_err location printing to assume less about GC internals
>>>      8229189: Improve JFR leak profiler tracing to deal with discontiguous heaps
>>>      8224815: Remove non-GC uses of CollectedHeap::is_in_reserved()
>>>      8224820: ZGC: Support discontiguous heap reservations
>>> 
>>> ...the remaining thing to do is plugging in a few platform specific ZGC files. This patch does that.
>>> Decided to go with mach_vm_map/mach_vm_remap to implement multi-mapping. Previously I didn't want to do that as I couldn't figure out how to mach_vm_remap memory on top of reserved VA (acquired using mmap). But apparently VM_FLAGS_OVERWRITE was the missing ingredient there. With that in place, dodging the terrible ftruncate implementation on macOS seemed like a good idea. That also implies this port supports large pages (unlike other GCs on macOS today). Yay!
> 
> Not completely related and not a review:
> 
> Please file an RFE with a link to this mechanism. It would be nice to do such changes in a generic way so that all collectors benefit in the future, not just one.
> 
> Its confusing as already is with one collector supporting this and other collectors supporting that, adding to that is not nice.
> 
> Thanks,
>  Thomas