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
4 files changed
