RFR: 8247691: [aarch64] Incorrect handling of VM exceptions in C1 deopt stub/traps

[Erik Österlund]

On Fri, 25 Sep 2020 13:54:51 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> The immediate issue that causes the error symptom is due to the procedure link register (LR) not being preserved across
>> the actual call to the "patching" function (in code generated from '_generate_patching()_'), invoked as part of the C1
>> deoptimization traps.  However, this update addresses a larger issue with the current implementation.
>> 
>> Since the Aarch64 implementation does not adopt patching but deoptimization to support load-mirror et.al., the
>> "patching" stub-code does not need to support the exception protocol otherwise necessary when a VM transition might be
>> needed in the actual patching function. The deoptimization is compulsory and the transition to the interpreter will
>> cater for proper interaction with the VM.  The proposed solution is thus: 1. The version of '_patch_code()_' used
>> with **DEOPTIMIZE_WHEN_PATCHING** should not be modelled as a **JRT_ENTRY**. The "patching" functions will not transfer
>> control to VM (for up-call or otherwise). 2. The patch-stub code does not need to handle the VM exception protocol
>> (code can be removed). 3. The patch-stub code need only to support deoptimization and re-execute (it's a fatal error
>> otherwise). 4. The patch-stub code does not need to utilise any instruction stream synchronisation barrier as no
>> patching/modifying of the instruction stream is done (including indirectly through a VM transition).
>
> Looks good.

> 
> *Mailing list message from [Andrew Dinn](mailto:adinn at redhat.com) on [hotspot-dev](mailto:hotspot-dev at openjdk.java.net):*
> 
> On 25/09/2020 17:45, Andrew Haley wrote:
> > Hmm. I left this code in because there always is a possibility that we
> > could enable C1 patching in the future. C1 patching does nothing
> > useful when we have tiered compilation because recompiles due to
> > tiered are ten times as common as recompiles due to patching needed,
> > so being able to patch makes almost no difference to run
> > time. However, there always was a possibility that some form of
> > "patching" might be possible, given appropriate code generation
> > strategies. This could be useful in small C1-only systems, in theory,
> > but I haven't seen any interest in such things.
> > 
> > On the other hand, I don't like dead code in the port and it's
> > probably time for it to die.
> > 
> > Anyone else have an opinion?
> 
> It's dead, Jim. I think it's time to take it away and bury it somewhere.
> We can always disinter it should resuscitation ever seem like a good
> idea (which doesn't seem too likely).
> 
> regards,
> 
> 
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill

+1.

Should we need this stuff in the distant future, we can just revive it then, should that happen.

-------------

PR: https://git.openjdk.java.net/jdk/pull/344