| 00b53b7f3f9ce5996b767b52c28dd846f47a723c |
|
03-Feb-2016 |
Alexey Frunze <Alexey.Frunze@imgtec.com> |
Fast ART MIPS64 interpreter
Change-Id: I5dda522df0acf9f9df626fe4f5ecfe6c4df600d3
|
| 6cbe0814952bd3bbb329c4ca4dc683ac87c2c2de |
|
01-Mar-2016 |
Serguei Katkov <serguei.i.katkov@intel.com> |
Revert "Revert "Fast ART x86_64 interpretator""
CFI is updated. Now unwinder can fall through fast interpreter.
This reverts commit c4a575f58007036ff3408b15c2ec48108add20f3.
Change-Id: Ibb0a2ef41e4d02ab0b4ecc4f030ba0e72971aa9d
Signed-off-by: Serguei Katkov <serguei.i.katkov@intel.com>
|
| c4a575f58007036ff3408b15c2ec48108add20f3 |
|
26-Feb-2016 |
Nicolas Geoffray <ngeoffray@google.com> |
Revert "Fast ART x86_64 interpretator"
Fails gcstress configuration.
This reverts commit c669beb798e273dd3d44cfa6a7a95ff90eba7209.
Change-Id: Ifac92471f91a116fc271d0dde8356fbbb0a08048
|
| 200f040af3e4fe9e178cb63c90860d58d90ef665 |
|
26-Feb-2016 |
Douglas Leung <douglas.leung@imgtec.com> |
[MIPS] Add Fast Art interpreter for Mips32.
Change-Id: I6b9714dc8c01b8c9080bcba175faec1d2de08f8f
|
| c669beb798e273dd3d44cfa6a7a95ff90eba7209 |
|
14-Jan-2016 |
Serguei Katkov <serguei.i.katkov@intel.com> |
Fast ART x86_64 interpretator
Introduce the ART x86_64 fast interpreter.
Change-Id: I3649698eb251ac8acc98851969f9445f60d17b02
Signed-off-by: Serguei Katkov <serguei.i.katkov@intel.com>
|
| 3b0b4b9d09baae7234fc26b7970b3ec55560735e |
|
02-Feb-2016 |
Bill Buzbee <buzbee@google.com> |
Revert "Revert "ART: Mterp for arm64""
Looks like some of our assemblers disagree on valid arm64 assembly syntax
Force use of clang for art runtime. In a subsequent CL, will use form
that both gcc and clang accept.
This reverts commit 43f3fb960bce978df699c8a68a972be2a0d0d221.
Change-Id: Ice83072171ab502c43d492e2238b446c4814ea67
|
| 43f3fb960bce978df699c8a68a972be2a0d0d221 |
|
02-Feb-2016 |
Sebastien Hertz <shertz@google.com> |
Revert "ART: Mterp for arm64"
This reverts commit e0c269e0a5f50b1a551ddba1205f6e5b4b5e6c98.
The CL is causing build breakages on arm64 targets.
Change-Id: I7402fe34869258ae870c57308b2062e50d801bdd
|
| e0c269e0a5f50b1a551ddba1205f6e5b4b5e6c98 |
|
27-Jan-2016 |
buzbee <buzbee@google.com> |
ART: Mterp for arm64
Ready for review. All opcodes handled. All applicable run-tests pass.
Device boots to desktop in interpret-only mode.
Change-Id: I937d8bcf848a831e04d4b9de8d1914667a197d75
|
| 7c58bd41046bb9f87642caa0c2b094dc98be29ca |
|
20-Jan-2016 |
Bill Buzbee <buzbee@google.com> |
Revert "Revert "Fast ART x86 interpreter""
This reverts commit 2d093a1213cc2f85b5e5e02782332657c479eb94.
Disable x86 mterp compilation on Mac host builds (but keep enabled
for all target builds).
Change-Id: Ie355279f166d2964a786646ee53f065b7e0f5ede
|
| 2d093a1213cc2f85b5e5e02782332657c479eb94 |
|
20-Jan-2016 |
Bill Buzbee <buzbee@google.com> |
Revert "Fast ART x86 interpreter"
This reverts commit 99229c71efda9363faa571017c52a215c6e28f83.
Assembly syntax issue with the Mac build.
Change-Id: I271d18d31963fae46e4077ddd39313bec0b3a39e
|
| 99229c71efda9363faa571017c52a215c6e28f83 |
|
31-Dec-2015 |
Serguei Katkov <serguei.i.katkov@intel.com> |
Fast ART x86 interpreter
Port of ART Dalvik-style interpreter for x86.
See Bill's patch for details
https://android-review.googlesource.com/#/c/188977/
Included fixes
https://android-review.googlesource.com/#/c/196153/
ART: Mterp read barrier fix + minor cleanup
https://android-review.googlesource.com/#/c/196501/
ART: Mterp - remove redundant null check
Change-Id: If447e3a14088559e3aa0b82cb2c91721bea586ee
Signed-off-by: Serguei Katkov <serguei.i.katkov@intel.com>
|
| 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
|