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

Vitaly Davidovich vitalyd at
Thu Sep 10 11:25:02 UTC 2015

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.

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.

Would we exceed the complexity budget if posix systems would use memory
remapping and windows safepoints?

sent from my phone
On Sep 10, 2015 4:00 AM, "Andrew Haley" <aph at> wrote:

> Ha
> On 09/10/2015 02:17 AM, David Holmes wrote:
> > On 10/09/2015 12:01 AM, Andrew Haley wrote:
> >> On 09/09/2015 02:55 PM, David M. Lloyd wrote:
> >>> On 09/09/2015 08:17 AM, Andrew Haley wrote:
> >>>> On 09/09/2015 02:13 PM, David M. Lloyd wrote:
> >>>>> How would you hook into the safepoint to perform the unmapping?
> You'd
> >>>>> have to wait for all threads to arrive at safepoints, wouldn't you?
> >>>>
> >>>> Yes.  That happens in the VM already, e.g. when we need to revoke the
> >>>> bias of a lock.  It's a well-established mechanism.
> >>>
> >>> Could you extend the technique to other native resources as well?
> >>
> >> Yes, but of course there will be some back-pressure from HotSpot
> >> developers: it requires changes to the VM, and you have to be
> >> extremely careful not to cause a deadlock.
> >
> > Adding a new JVM_* function that requests a safepoint VM operation be
> > executed is not a major concern in my opinion**. Of more of a concern is
> > the cost of doing a stop-the-world safepoint in the kinds of
> > environments being described. How frequently are these unmap operations
> > needed?
> That's an interesting point.  I wonder if it might make sense to piggyback
> on a safepoint which would have happened anyway.  But having said that, we
> seem to be quite happy to safepoint for biased lock revocation and all
> manner of other things.
> Andrew.

More information about the core-libs-dev mailing list