History log of /art/runtime/interpreter/mterp/arm/op_return_wide.S
Revision Date Author Comments
3049324f4ef71b5d7a3de49bd77c75f07dbf8f3a 03-Nov-2016 Hiroshi Yamauchi <yamauchi@google.com> Make empty checkpoint work while weak ref access is disabled.

Fix a potential race on PushOntoMarkStack for CC by running an empty
checkpoint (while weak ref access is disabled).

Bug: 32508093
Bug: 12687968
Test: test-art-host with CC/CMS, libartd boot with N9, Ritz EAAC.
Change-Id: I3749bb525e7734804307ee16262355f3fc730312
ace690f5e440930d7bbad97fdbfdc3eb65e230be 11-Mar-2016 buzbee <buzbee@google.com> ART: mterp arm/arm64 cleanup

Assembly code cleanup in response to comments from already-submitted
CL: https://android-review.googlesource.com/#/c/188977/

Change-Id: I0ea85c5759a08cb50ef3e97dc5cf79b3ba041640
a2c97a94ee9379b23204bfef87afacd4b60cae37 26-Jan-2016 buzbee <buzbee@google.com> [WIP] ART Mterp: fix for hidden gc roots

To support moving gc, we must not hold onto any references solely
in registers across potential gc points. This was happening during
returns, instance-of and check-cast.

[testing in progress]

Change-Id: I367750658c5716960737f0666e46800240fd392d
1452bee8f06b9f76a333ddf4760e4beaa82f8099 06-Mar-2015 buzbee <buzbee@google.com> Fast Art interpreter

Add a Dalvik-style fast interpreter to Art.
Three primary deficiencies in the existing Art interpreter
will be addressed:

1. Structural inefficiencies (primarily the bloated
fetch/decode/execute overhead of the C++ interpreter
implementation).
2. Stack memory wastage. Each managed-language invoke
adds a full copy of the interpreter's compiler-generated
locals on the shared stack. We're at the mercy of
the compiler now in how much memory is wasted here. An
assembly based interpreter can manage memory usage more
effectively.
3. Shadow frame model, which not only spends twice the memory
to store the Dalvik virtual registers, but causes vreg stores
to happen twice.

This CL mostly deals with #1 (but does provide some stack memory
savings). Subsequent CLs will address the other issues.

Current status:
Passes all run-tests.
Phone boots interpret-only.
2.5x faster than Clang-compiled Art goto interpreter on fetch/decode/execute
microbenchmark, 5x faster than gcc-compiled goto interpreter.
1.6x faster than Clang goto on Caffeinemark overall
2.0x faster than Clang switch on Caffeinemark overall
68% of Dalvik interpreter performance on Caffeinemark (still much slower,
primarily because of poor invoke performance and lack of execute-inline)
Still nearly an order of magnitude slower than Dalvik on invokes
(but slightly better than Art Clang goto interpreter.
Importantly, saves ~200 bytes of stack memory per invoke (but still
wastes ~400 relative to Dalvik).

What's needed:
Remove the (large quantity of) bring-up hackery in place.
Integrate into the build mechanism. I'm still using the old Dalvik manual
build step to generate assembly code from the stub files.
Remove the suspend check hack. For bring-up purposes, I'm using an explicit
suspend check (like the other Art interpreters). However, we should be
doing a Dalvik style suspend check via the table base switch mechanism.
This should be done during the alternative interpreter activation.
General cleanup.
Add CFI info.
Update the new target bring-up README documentation.
Add other targets.

In later CLs:
Consolidate mterp handlers for expensive operations (such as new-instance) with
the code used by the switch interpreter. No need to duplicate the code for
heavyweight operations (but will need some refactoring to align).
Tuning - some fast paths needs to be moved down to the assembly handlers,
rather than being dealt with in the out-of-line code.
JIT profiling. Currently, the fast interpreter is used only in the fast
case - no instrumentation, no transactions and no access checks. We
will want to implement fast + JIT-profiling as the alternate fast
interpreter. All other cases can still fall back to the reference
interpreter.
Improve invoke performance. We're nearly an order of magnitude slower than
Dalvik here. Some of that is unavoidable, but I suspect we can do
better.
Add support for our other targets.

Change-Id: I43e25dc3d786fb87245705ac74a87274ad34fedc