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