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

Mike Hearn hearn at
Tue Sep 8 20:13:12 UTC 2015

> I think that MR is referring to Windows when he talks about
> race conditions.

The race can happen on any platform if you can't do an atomic unmap of a
file and remap to some kind of guard page. I guess on Linux you can, maybe?
I've never tried it.

It may be that on Windows if you remap a file mapping with VirtualAllocEx,
and then close the underlying handle, the guard mapping sticks around and
you can then delete/rename the underlying file.

If not then this appears to be one of those unfortunate sun.misc.Unsafe
equivalents, where the safe way doesn't exist, and the unsafe way that
developers are currently using successfully is going to vanish :(

If there isn't a clever ordering on Windows that works I'd be A-OK with
just trading off a bit of safety when there's no SecurityManager present.
The proposed race is likely to be exceptionally rare on 64 bit systems and
it seems the alternative is either don't use MappedByteBuffer, or override
Jigsaw and get access to the internal Cleaner API back again.

More information about the core-libs-dev mailing list