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

Patric Hedlin phedlin at openjdk.java.net
Sat Sep 26 18:27:23 UTC 2020


On Thu, 24 Sep 2020 19:14:54 GMT, Patric Hedlin <phedlin 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).

This pull request has now been integrated.

Changeset: 7817963c
Author:    Patric Hedlin <phedlin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7817963c
Stats:     94 lines in 3 files changed: 15 ins; 60 del; 19 mod

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

Reviewed-by: eosterlund, aph

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

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


More information about the hotspot-dev mailing list