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

[Andrew Haley]

On 09/10/2015 03:56 PM, Vitaly Davidovich wrote:
>     Sure, if you like, but that's a detail.  We are arguing about what
>     colour to paint the bike shed.  :)
>  
> The reason it may be more than just a bikeshed is because if this requires more cleverness in the segfault handler, then it's yet more work to make this happen.  I agree it's an implementation detail, but I don't think it's trivial (unless someone comes along and says that modifying the trap handler to account for this type of scenario is trivial).

I don't think that it's exactly trivial, but I've spent a fair bit of
time inside that segfault handler so I have a pretty good idea.  It is
somewhat troublesome that each OS and CPU has its own version.

> One would also need to modify the safepoint code in the VM to allow skipping all the housekeeping it does typically, but I suspect this part is fairly easy.
> 
> At any rate, this is probably the best that can be done if we don't want to expose the unsafe method.  Part of me wonders whether this attempt to preserve JVM integrity is really worth the cost; there're already ways to bring down the JVM (e.g. JNI, existing Unsafe usage, etc), and so putting a safety perimeter around this piece seems uninteresting (especially given that people today are already using unsafe hacks for this). 

I take your point.  However, I really like the idea of "Java as fast
as C, but safer!" for handling native data and think it's worth
expending a little effort on.

> I do think, however, that avoiding safepoints on systems that allow atomic remapping would be needed, although that increases the complexity of the solution somewhat.

Fair enough.

Andrew.