Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
aph at redhat.com
Thu Sep 10 13:22:27 UTC 2015
On 09/10/2015 12:25 PM, Vitaly Davidovich wrote:
> The safepoint happiness is unfortunately a separate issue in
> Hotspot, and it's definitely not happy times :). Part of the
> problem is the piggybacking of various operations on a safepoint -
> the safepoint time alone (not counting GC, say) keeps growing. You
> probably could piggyback this on GuaranteedSafepointInterval
> safepoints, but those are currently predicated on IC buffers needing
> to be cleaned.
OK. I see that there is a conflict here.
> As for biased locking, you'll find many deployments that care about
> latency turn it off entirely (it's not a very useful feature on
> modern hardware, at least X86/64) precisely to avoid revocation
> induced global pauses.
Indeed so, yes. (But biased locking seems to be the default. Is that
a good thing?)
> Would we exceed the complexity budget if posix systems would use
> memory remapping and windows safepoints?
I can still see address space exhaustion happening on unices.
On AArch64 we use either 3 or or 4 levels of translation tables with
4k pages, which gets us 512GB or 256TB of space. With 64k pages 2
levels of translation tables are used, and that gets us 4TB of address
space. If you map a few big databases it's really not going to take
very long to run out of space.
I guess it could be a runtime switch, like everything else. :-)
More information about the core-libs-dev