summaryrefslogtreecommitdiff
path: root/test/ProfileTestMultiDex/Main.java
diff options
context:
space:
mode:
authorSebastien Hertz <shertz@google.com>2015-01-16 19:49:09 +0100
committerSebastien Hertz <shertz@google.com>2015-01-23 18:00:39 +0100
commit90a33595bc637f5768a7726a186bdfe25efcd0d6 (patch)
tree901a4e48313d497b784f5fca3f88b0405d6a8dec /test/ProfileTestMultiDex/Main.java
parent92fbd284fa595724c47d1a803b50c3891b9836b3 (diff)
Fix exception handling during deoptimization
When interpreting a deoptimized shadow frame, we may start with a pending exception thrown by a previous deoptimized shadow frame (from a previous invoke). Therefore, we need to handle it before executing any instruction, otherwise we execute incorrect code. Because we need the DEX pc of the throwing instruction to find a matching catch handler, we initialize deoptimized shadow frames with the current DEX pc at the time the stack is deoptimized. When we are about to interpret a deoptimized shadow frame, we need to update the shadow frame with the DEX pc of the next instruction to interpret. There are three cases: - if there is no pending exception, this is the instruction following the current one. - if there is a pending exception and we found a matching catch handler, this is the first instruction of this handler. - if there is a pending exception but there is no matching catch handler, we do not execute the deoptimized shadow frame and continue to its caller. The verifier now fails when a method starts with a move-exception instruction. Indeed we cannot start executing a method with a pending exception. Bug: 19057915 Bug: 19041195 Bug: 18607595 (cherry picked from commit 270a0e16c3b8e5b95cbfdbd8996ac137c7c6322b) Change-Id: Ib4fdd0ad704b4f2369d229737c9cc77f559cea55
Diffstat (limited to 'test/ProfileTestMultiDex/Main.java')
0 files changed, 0 insertions, 0 deletions