> > 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 <a...@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. >
