Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

Andrew Haley aph at
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 mailing list