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

Andrew Haley aph at redhat.com
Fri Sep 25 16:45:59 UTC 2020


On 25/09/2020 11:27, Patric Hedlin wrote:

> 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 no 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).

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?

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671



More information about the hotspot-dev mailing list