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.

Reply via email to