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

Andrew Haley aph at
Wed Sep 9 12:52:16 UTC 2015

On 09/09/2015 01:46 PM, Mike Hearn wrote:
> I guess, although it's ugly, a system property could control whether the
> NIO implementation returns an ordinary MappedByteBuffer or a new subclass,
> the UnmappableMappedByteBuffer. HotSpot would then be responsible for
> removing the overhead of the virtual calls, as normal. If a customer finds
> that the guard page write is causing performance issues for them, they
> could use the system property to get the hold behaviour back and the unmap
> call would throw.
> But it sounds like users with extreme VMM needs, like Lucene, would find
> this a performance win rather than a loss.

I don't like that much: I'd much rather have a wrapper around a
MappedByteBuffer: a closeable MappedByteBuffer, if you like.  But
really, that's just a quibble about details, and is a little


More information about the core-libs-dev mailing list