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

[Vitaly Davidovich]

>
> 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).  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 do think,
however, that avoiding safepoints on systems that allow atomic remapping
would be needed, although that increases the complexity of the solution
somewhat.

On Thu, Sep 10, 2015 at 10:45 AM, Andrew Haley <aph at redhat.com> wrote:

> On 09/10/2015 03:35 PM, Vitaly Davidovich wrote:
>
> > Well, you'd probably want something other than NPE here -- perhaps a
> > new dedicated exception to signal this condition.
>
> Sure, if you like, but that's a detail.  We are arguing about what
> colour to paint the bike shed.  :)
>
> > And this means the segfault handling now needs to know about this
> > type of situation as well, rather than just NPEs.
>
> Maybe, but perhaps not.  The access to the guard page might just
> trigger the usual segfault path, which (given an oop map) looks just
> like a null pointer exception.
>
> Andrew.
>