[rfc][ARM] Support for safepoint check based on memory protect rather than polling

[Andrew Haley]

On 05/16/2012 09:28 AM, Andrew Dinn wrote:
> On 15/05/12 19:01, Andrew Haley wrote:
>> On 05/15/2012 10:12 AM, Andrew Dinn wrote:
>>>> I'm not really convinced that all this magic word stuff is necessary.
>>>>> I guess if someone other than a safepoint check does fault we'll see
>>>>> it in the backtrace, so this is OK.  But is it really worth all the
>>>>> complexity?
>>
>>> If we remove this check and some bug happens to invalidly read or write
>>> the safepoint page then we will blithely skip the PC forwards 6 or 8
>>> bytes and return from the signal handler i.e. trying to continue
>>> execution from wherever that adjustment takes us. We might be lucky and
>>> see another SEGV or an  illegal instruction causing a fatal exit.
>>> However, we might also be unlucky and continue Java execution with
>>> corrupt Java or VM data. I would not want to debug the latter -- the
>>> error might manifest many instructions later.
>>
>> Well, yes.  But we don't check that some rogue code elsewhere hasn't,
>> say, corrupted the stack either.  What's different about this?
> 
> What is different is that instead of having the JVM stop at the SEGV we
> adjust the PC and continue execution. This may only occur in a small
> number of cases but it means that instead of detecting an easibly
> detectable error and failing early (always a good principle if detection
> is cheap) we almost certainly delay the failure until later. That risks
> making the error much more opaque. If (when?) such a SEGV happens
> identifying what has gone on will likely be a nasty maintenance problem.
> That compounds the standard risk from propagating any program state
> corruption i.e. potentially serious consequences for the integrity of
> user data.

OK, but I still don't see how this is any different from any one of
a million possible things we could check.  It's an assertion, really.
But assertions get turned off.

> What are the costs of detecting:

The most important cost is cache pressure.  But OK, I'll reluctantly
go along with it.

Andrew.