| 0d615c3ce5bf97ae65b9347ee77968f38620d5e8 |
|
18-Aug-2010 |
Andy McFadden <fadden@android.com> |
Always support debugging and profiling.
This eliminates the use of the WITH_DEBUGGER and WITH_PROFILER
conditional compilation flags. We've never shipped a device without
these features, and it's unlikely we ever will. They're not worth
the code clutter they cause.
As usual, since I can't test the x86-atom code I left that alone and
added an item to the TODO list.
Bug 2923442.
Change-Id: I335ebd5193bc86f7641513b1b41c0378839be1fe
|
| 7a2697d327936e20ef5484f7819e2e4bf91c891f |
|
07-Jun-2010 |
Ben Cheng <bccheng@android.com> |
Implement method inlining for getters/setters
Changes include:
1) Force the trace that ends with an invoke instruction to include
the next instruction if it is a move-result (because both need
to be turned into no-ops if callee is inlined).
2) Interpreter entry point/trace builder changes so that return
target won't automatically be considered as trace starting points
(to avoid duplicate traces that include the move result
instructions).
3) Codegen changes to handle getters/setters invoked from both
monomorphic and polymorphic callsites.
4) Extend/fix self-verification to form identical trace regions and
handle traces with inlined callees.
5) Apply touchups to the method based parsing - still not in use.
Change-Id: I116b934df01bf9ada6d5a25187510e352bccd13c
|
| de66fcbc1d7fde20bdafb508b769028d8f2ec9bc |
|
30-Jul-2010 |
Elliott Hughes <enh@google.com> |
Switch -Xjnitrace over to using a custom JNI bridge.
This now works without needing to specify -Xint:portable, and no longer needs
to be manually enabled at compile-time.
If you're using -Xjnitrace, you'll pay to look up the real JNI bridge on every
invocation of a native method, but doing so leads to a really simple
implementation, and you're writing to the log on every invocation anyway, so
-Xjnitrace and performance don't go together anyway.
Bug: 2846017
Change-Id: I3108c4f35f27b72e8849c41077ae3e8768550e96
|
| 8afa9dfe04354e5b3917e31e3e2772885f507580 |
|
07-Jul-2010 |
Elliott Hughes <enh@google.com> |
Tracing for developers of native methods.
The existing -verbose:jni is mainly useful for VM developers hacking on the JNI
implementation; this is intended to replace the ad hoc logging developers of
native methods need to write.
Use "-Xint:portable -Xjnitrace:ClassNameSubstring" on the command line. To
trace all native methods (mainly useful for testing the tracing), use
"-Xjnitrace:"; to trace just methods in java.util.regex.Matcher, use
"-Xjnitrace:Matcher" or "-Xjnitrace:Ljava/util/regex/Matcher;" or whatever.
To trace all the methods in Matcher and Pattern, you have to use something
like "-Xjnitrace:java/util/regex/". There's no facility for tracing an
individual method or group of methods because I haven't needed such a thing.
Here's a basic example:
-> Ljava/nio/charset/Charsets;.toUtf8Bytes([CII)[B (0x400474b8, 0, 5)
<- Ljava/nio/charset/Charsets;.toUtf8Bytes([CII)[B returned 0x40047548
Here's an example of a non-static native method:
-> Lorg/apache/harmony/luni/platform/OSFileSystem;.writeImpl(I[BII)J this=0x40012e78 (1, 0x400476d0, 0, 5)
<- Lorg/apache/harmony/luni/platform/OSFileSystem;.writeImpl(I[BII)J returned 5
Here's an interesting example showing another native method being called, and
an exception being thrown by a native method:
-> Ljava/lang/VMClassLoader;.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; (0x400466b8, false)
-> Ljava/lang/Throwable;.nativeFillInStackTrace()Ljava/lang/Object; ()
<- Ljava/lang/Throwable;.nativeFillInStackTrace()Ljava/lang/Object; returned 0x400467c8
<- Ljava/lang/VMClassLoader;.loadClass(Ljava/lang/String;Z)Ljava/lang/Class; threw Ljava/lang/ClassNotFoundException;
(This functionality needs to be enabled at compile time. A later patch will
address that.)
Change-Id: I6da8930bd4b4f228e07b05cc59a3aea331c5cee1
|
| 364f9d924cbd9d392744a66f80cc084c3d80caf0 |
|
12-Jun-2010 |
Barry Hayes <bhayes@google.com> |
Put wrappers on all stores of Object pointers into heap Objects.
Also:
Changed ++ loops to [i] loops where I'm touching.
Added some asserts.
Added dvmHeapSourceContainsAddress
Added dvmIsValidObjectAddress
Change-Id: I6586688246064aecabb1e22e1dca276fecee7795
|
| c35a2ef53d0cccd6f924eeba36633220ec67c32e |
|
17-Jun-2010 |
Andy McFadden <fadden@android.com> |
Add opcodes for volatile field accesses
This adds instructions for {i,s}{get,put}{,-object}-volatile, for a
total of eight new instructions.
On SMP systems, these instructions will be substituted in for existing
field access instructions, either by dexopt or during just-in-time
verification. Unlike the wide-volatile instructions, these will not be
used at all when the VM is not built for SMP.
(Ideally we'd omit the volatile instruction implementations entirely on
non-SMP builds, but that requires a little work in gen-mterp.py.)
The change defines and implements the opcodes and support methods, but
does not cause them to be used.
Also, changed dvmQuasiAtomicRead64's argument to be const.
Change-Id: I9e44fe881e87f27aa41f6c6e898ec4402cb5493e
|
| fbdcfb9ea9e2a78f295834424c3f24986ea45dac |
|
29-May-2010 |
Brian Carlstrom <bdc@google.com> |
Merge remote branch 'goog/dalvik-dev' into dalvik-dev-to-master
Change-Id: I0c0edb3ebf0d5e040d6bbbf60269fab0deb70ef9
|
| fc075c2d1ae63c26f96e0c6eeb72efc898dbebbf |
|
29-May-2010 |
Ben Cheng <bccheng@android.com> |
Clean up warnings detected by gcc.
Also re-enabled the JIT for the ARMv5te target.
Change-Id: I89fd229205e30e6ee92a4933290a7d8dca001232
|
| cbbd0bedb75b75b99c1112e1f433386a14661b0b |
|
11-May-2010 |
Ben Cheng <bccheng@android.com> |
Add the dummy CHECK_JIT and ABORT_JIT_TSELECT macros even when JIT is off.
Change-Id: I5d9886dcb8359dd4336d83b2a2bddad383f5cc36
|
| dd6e87095071e4e987910732062545f7303023e5 |
|
07-May-2010 |
Ben Cheng <bccheng@android.com> |
Abandon a JIT trace if it contains static fields that are not fully initialized
Also turn some asserts into aborts to capture future contract changes between
the VM and the JIT.
Bug: 2655384
Change-Id: I8bb0226c7ae26fedf6b4ad25a1cd1aa7013b60d4
|
| 861b33855aff080278ea5125e4372a2d4bf8aef5 |
|
06-Mar-2010 |
Andy McFadden <fadden@android.com> |
Make wide-volatile loads and stores atomic.
This implements the four wide-volatile instructions added in a previous
change, and modifies the verifier to substitute the opcodes into the
instruction stream when appropriate.
For mterp, the ARM wide get/put instructions now have conditional code
that replaces ldrd/strd with a call to the quasiatomic functions. The
C version does essentially the same thing. ARMv4T lacks ldrd/stdrd, and
uses separate implementations for the wide field accesses, so those were
updated as well. x86 will just use stubs.
The JIT should punt these to the interpreter.
Change-Id: Ife88559ed1a698c3267d43c454896f6b12081c0f
Also:
- We don't seem to be using the negative widths in the instruction
table. Not sure they're useful anymore.
- Tabs -> spaces in x86-atom throw-verification-error impl.
|
| 5387824f19033ed51a945fbc8c2b574998404b3d |
|
05-Mar-2010 |
Andy McFadden <fadden@android.com> |
Add instructions for volatile wide fields.
This adds four new instructions for accessing volatile wide fields (long
and double). The JLS requires that such accesses are atomic, but the
VM doesn't otherwise make guarantees about the atomicity of reads and
writes on 64-bit fields.
There are no behavioral changes. This just adds definitions for the new
instructions and a couple of tests. The current implementation is just
the non-volatile form of the instructions or a C stub, but since we're
not generating them it doesn't really matter yet.
Also:
- bumped Dalvik version to 1.3.0
- added a note to the x86-atom TODO list
For bug 1633591.
|
| 4abe4014d3fa6fcdaff6869ca1d60de15a72d124 |
|
26-Feb-2010 |
Andy McFadden <fadden@android.com> |
Update a few things in x86-atom.
This replaced unuses opcodes EC and EF with C stubs for the breakpoint
and execute-inline/range instructions, which were added after the last
bunch of stuff we rolled out to eclair open-source. I also rebuilt the
"out" dir to pick up the various other changes.
|
| 22d404a75a00cda0b0ebed1034c2808ba060b05f |
|
07-Apr-2009 |
Johnnie Birch <johnnie.l.birch.jr@intel.com> |
This is a contribution of x86-atom targeted assembly for the fast byte-code interpreter engine. This is an initial contribution with minimal optimizations that target the Intel ATOM processor. We expect to continuously improve this code. It is expected that there will be a discussion on the potential merge of this code and similar efforts (i.e. the mterp/x86 directory first included with cupcake). While this code is intended to target ATOM and not a generic X-86 processor, we were able to show the following improvements over the c-portable interpreter using the simulator build:
Build: TARGET_SIMULATOR: true
TARGET_BUILD_TYPE: release
TARGET_PRODUCT: sim
Environment: Intel(R) Core(TM)2 Quad CPU Q9550 @ 2.83GHz
PI = Portable Interpreter
IA = Fast IA Interpreter
Embedded CaffeineMark: (IA-PI)/PI: Average of 70% improvement on overall score
SPECjbb2000*: (IA-PI)/PI: Average of 37% improvement on raw score
SPECjvm98*: (PI/IA) Speedup: Mtrt: 1.2; Jess: 1.34; Compress: 1.57; Db: 1.46; Jack: 1.28
* SPECjbb2000 - 1 warehouse. Noncompliant - modified to run on Dalvik
* SPECjvm98 - Noncompliant - modified to run on Dalivk
|