History log of /dalvik/vm/compiler/template/out/CompilerTemplateAsm-ia32.S
Revision Date Author Comments
d585beda3690b8b5b978e3c59af224336614ba72 21-May-2013 Yanchuan Nian <ycnian@gmail.com> Rename unreasonable function name dmvCompilerTemplateEnd

In dalvik, most function names start with "dvm" except dmvCompilerTemplateEnd.
Convert it to dvmCompilerTemplateEnd in order to follow the rule.

Change-Id: I09c41f8c9d55058013fbdb62ac5922ccd067ce39
5dfcc78af479937ba8dafceefd9b1931a88dfaaf 11-Aug-2012 Ard Biesheuvel <ard.biesheuvel@gmail.com> hardening: eliminate all text relocations from lidbvm

This patch consists of:
- changes to mterp/ that turn all literals from absolute
to PC relative, so the relocations can be resolved at
(build) link time
- changes to compiler/template/ that result in the
compiler templates to live in the non-executable
.data.rel.ro section (this code is never executed
directly, only from the jit heap, so there is no
reason to put it in the .text section)

Change-Id: I2dc97bd4720b393a74b7277a188f0c7b681fc932
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@gmail.com>
9f601a917c8878204482c37aec7005054b6776fa 12-Feb-2011 buzbee <buzbee@google.com> Interpreter restructuring: eliminate InterpState

The key datastructure for the interpreter is InterpState.
This change eliminates it, merging its data with the Thread structure.

Here's why:

In principio creavit Fadden Thread et InterpState. And it was good.

Thread holds thread-private state, while InterpState captures data
associated with a Dalvik interpreter activation. Because JNI calls
can result in nested interpreter invocations, we can have more than one
InterpState for each actual thread. InterpState was relatively small,
and it all worked well. It was used enough that in the Arm version
a register (rGLUE) was dedicated to it.

Then, along came the JIT guys, who saw InterpState as a convenient place
to dump all sorts of useful data that they wanted quick access to through
that dedicated register. InterpState grew and grew. In terms of
space, this wasn't a big problem - but it did mean that the initialization
cost of each interpreter activation grew as well. For applications
that do a lot of callbacks from native code into Dalvik, this is
measurable. It's also mostly useless cost because much of the JIT-related
InterpState initialization was setting up useful constants - things that
don't need to be saved and restored all the time.

The biggest problem, though, deals with thread control. When something
interesting is happening that needs all threads to be stopped (such as
GC and debugger attach), we have access to all of the Thread structures,
but we don't have access to all of the InterpState structures (which
may be buried/nested on the native stack). As a result, polling for
thread suspension is done via a one-indirection pointer chase. InterpState
itself can't hold the stop bits because we can't always find it, so
instead it holds a pointer to the global or thread-specific stop control.

Yuck.

With this change, we eliminate InterpState and merge all needed data
into Thread. Further, we replace the decidated rGLUE register with a
pointer to the Thread structure (rSELF). The small subset of state
data that needs to be saved and restored across nested interpreter
activations is collected into a record that is saved to the interpreter
frame, and restored on exit. Further, these small records are linked
together to allow tracebacks to show nested activations. Old InterpState
variables that simply contain useful constants are initialized once at
thread creation time.

This CL is large enough by itself that the new ability to streamline
suspend checks is not done here - that will happen in a future CL. Here
we just focus on consolidation.

Change-Id: Ide6b2fb85716fea454ac113f5611263a96687356
13fbc2e4bfa04cce8e181ac37d7f2b13a54aa037 14-Dec-2010 buzbee <buzbee@google.com> Stamp out some x86/host mode warnings

Nuked a void* cast warnings and moved cacheflush into a target-specific
utility wrapper.

Change-Id: I36c841288b9ec7e03c0cb29b2e89db344f36fad1
dfd1bbf07d98c82a6072182f705f64a30ebf480b 23-Sep-2010 buzbee <buzbee@google.com> Experimental x86 Jit trace selection

Experimental support for trace selection for x86 host mode operation.
Not enabled by default. Turned on by setting WITH_HOST_DALVIK true
and WITH_JIT true. When enabled, profiles during x86 fast interpreter
operation, selects hot traces and "compiles" traces consisting of jumps
back to the interpreter.

First in a series of experimental x86 support checkins.

Change-Id: I0e423ec58a7bf01f226cb486f55de2841fab1002
8c9ac9ab0ab6fd75b73cb0d99005da3aa90c167c 22-Oct-2010 Ben Cheng <bccheng@android.com> Avoid conditional loads if WORKAROUND_CORTEX_A9_745320 is defined.

No noticeable performance impact by this change.

Bug: 3117632
Change-Id: I31c6adc6cb9999498bb456f1e87f6f04f33e4144
c8293e7dfe856ca95e27aef1ac2e64d750d60662 12-Oct-2010 Ben Cheng <bccheng@android.com> Fine-tune the instructions on the method invocation path.

1) Initialize the register and out sizes for callee methods through
constant moves.
2) Eliminate an unnecessary load of Dalvik PC for chained and
native callees.

Improved method invocation performance by ~3%.

Change-Id: Iead1276eed0ba527e82eb876f08d169ab9b496b2
7520ee7ff226e12e06818561b15741d2575072e3 18-Sep-2010 buzbee <buzbee@google.com> Add source code skeletons for x86 work. No actual JIT'ng yet.

Change-Id: Ic94a916e777e9bc5163cf205899daf9c18dcafe1