summaryrefslogtreecommitdiffstats
path: root/runtime/dex_instruction.h
diff options
context:
space:
mode:
authorbuzbee <buzbee@google.com>2014-02-27 12:55:32 -0800
committerbuzbee <buzbee@google.com>2014-02-27 14:51:37 -0800
commitb1f1d642093418612c0a27ce4203b421bb6eb767 (patch)
treebb30f5246ec96d838e493aadccfc604d305f5a39 /runtime/dex_instruction.h
parent7aa9ac0b25c9f391fd87f72edbf14baab9da918f (diff)
downloadandroid_art-b1f1d642093418612c0a27ce4203b421bb6eb767.tar.gz
android_art-b1f1d642093418612c0a27ce4203b421bb6eb767.tar.bz2
android_art-b1f1d642093418612c0a27ce4203b421bb6eb767.zip
Workaround for range ops spanning vreg gap
The Dalvik runtime model includes two stacks: an interpreted stack holding the Dalvik virtual registers, and a native stack used by the runtime system itself. The interpreted stack closely follows the Dalvik byte-code frame layout and invoke model, in which a callee's incoming argument are physically located in the out region of the caller's frame. Further, the non-argument vregs of a method are contiguous with its in argument region. The Art runtime model retains the notion of a callee's incoming arguments being physically located in the out region of a caller's frame. However, because Art uses a single-stack model, a method's incoming argument region is not contiguous with its non-argument virtual register storage. There is a gap between them that is used to store the native return PC of the caller, as well as the callee save register spill region. The Dalvik's bytecode instruction set includes several "range" format instructions (invoke-static-range, fill-array-data-range, etc.). These instructions define a contiguous range of virtual registers as arguments. Given the current Dalvik bytecode definition, there is no rule preventing an operand range from spanning the incoming argument and normal vregs. In Dalvik, this would not have been an issue. In Art, it adds complexity to correctly copy a range of arguments with a potential gap somewhere in the middle. We don't believe this is a common situation. This workaround CL ensures correct behavior by detecting the spanning case and falling back to the interpreter. If it turns out this is a more common case than expected, compiler support can be added. More likely, though, is that we will disallow spanning ranges in a future revision of the bytecode (going forward, existing range-spanning bytecode will continue to be supported). Fix for internal tracking bug 13216301 Fix for external bug https://code.google.com/p/android/issues/detail?id=66371 Change-Id: I9562aa5ab0aae8ebf333c8b72caac8a1be33ab3c
Diffstat (limited to 'runtime/dex_instruction.h')
-rw-r--r--runtime/dex_instruction.h5
1 files changed, 5 insertions, 0 deletions
diff --git a/runtime/dex_instruction.h b/runtime/dex_instruction.h
index c434cdd938..4352c4add0 100644
--- a/runtime/dex_instruction.h
+++ b/runtime/dex_instruction.h
@@ -422,6 +422,11 @@ class Instruction {
return kInstructionFlags[opcode];
}
+ // Return the verify flags for the given opcode.
+ static int VerifyFlagsOf(Code opcode) {
+ return kInstructionVerifyFlags[opcode];
+ }
+
// Returns true if this instruction is a branch.
bool IsBranch() const {
return (kInstructionFlags[Opcode()] & kBranch) != 0;