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

Erik Österlund erik.osterlund at oracle.com
Mon Oct 28 16:11:42 UTC 2019


Hi,

After some internal discussions with Per and Stefan, some refactorings 
have been made:

1) Use mmap consistently wherever possibly, instead of mach_vm_map, for 
consistency. And only use mach_vm_remap from a wrapper function to map 
in views.
2) Move the pmem segments up one level so that producer and consumer of 
the segments is on the same level, and let the virtual "file" know only 
about offsets.
3) Minor polishing.

Incremental:
http://cr.openjdk.java.net/~eosterlund/8224817/webrev.00..01/

Full:
http://cr.openjdk.java.net/~eosterlund/8224817/webrev.01/

Thanks,
/Erik

On 2019-10-24 12:38, 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!
>
> CR:
> http://cr.openjdk.java.net/~eosterlund/8224817/webrev.00/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8229358
>
> Thanks,
> /Erik




More information about the hotspot-gc-dev mailing list