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

[Andrew Dinn]

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.

What are the costs of detecting:

1) compile time costs -- we have to plant the extra magic word at
compile time and we have to work out whether to plant a 4 or 6 byte
offset in the read instruction -- this is fairly small especially as it
only occurs once per compiled method.

2) runtime costs -- in the signal handler we have to subtract the
address from the poll page base to derive the offset and pass this extra
parameter to the poll check routine plus check the return value. in the
poll adjust routine we have to read and test the magic word and maybe
branch if we decide this is a real SEGV rather than a poll request SEGV.
We also have an extra value to add when adjusting the PC. These are also
small costs especially as safepoint checks don't happen very often.

3) maintenance costs -- the code is a little more tricky to understand.
That said, I assume that anyone who can understand how the flow of
control is adjusted via a signal handler monkeying with the PC ought to
have little problem with following this extra detail, especially as it
is fully commented.

regards,


Andrew Dinn
-----------