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.