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.
