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

[Vitaly Davidovich]

Whether biased locking being enabled by default is up for debate; my
opinion is it should be off on modern CPUs.  If you're not contending, CAS
isn't much of an issue.  If you are contending, then you'll get revocations
which is more expensive than the CAS.  Biased locking would be profitable
on hardware where CAS is very expensive even if on uncontended cacheline.

If you remap to a none protected page, why is address exhaustion an issue?
It's the same thing you're suggesting without safepoint requirement.

sent from my phone
On Sep 10, 2015 9:22 AM, "Andrew Haley" <aph at redhat.com> wrote:

> 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.  :-)
>
> Andrew.
>