Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)
Andrew Haley
aph at redhat.com
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
premature.
Andrew.
More information about the core-libs-dev
mailing list