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
|
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
|
fbdcfb9ea9e2a78f295834424c3f24986ea45dac |
|
29-May-2010 |
Brian Carlstrom <bdc@google.com> |
Merge remote branch 'goog/dalvik-dev' into dalvik-dev-to-master Change-Id: I0c0edb3ebf0d5e040d6bbbf60269fab0deb70ef9
|
bd0472480c6e876198fe19c4ffa22350c0ce57da |
|
13-May-2010 |
Bill Buzbee <buzbee@google.com> |
JIT: Fix for [Issue 2675245] FRF40 monkey crash in jit-cache The JIT's chaining mechanism suffered from a narrow window that could result in i-cache inconsistency. One of the forms of chaining cell consisted of a two 16-bit thumb instruction sequence. If a thread were interrupted between the execution of those two instructions *and* another thread picked that moment to convert that cell's chained/unchained state, then bad things happen. This CL alters the chain/unchain model somewhat to avoid this case. Chainable chaining cells grow by 4 bytes each, and instead of rewriting a 32-bit cell to chain/unchain, we switch between chained and unchained state by [re]writing the first 16-bits of the cell as either a 16-bit Thumb unconditional branch (unchained mode) or the first half of a 32-bit Thumb branch. The 2nd 16-bits of the cell will never change once the cell moves from its inital state - thus avoiding the possibility of it becoming inconsistent. This adds a trivial execution penalty on the slow path, but will add about a kByte of memory usage to a typical process. Change-Id: Id8b99802e11386cfbab23da6abae10e2d9fc4065
|
9a8c75adb2abf551d06dbf757bff558c1feded08 |
|
08-Nov-2009 |
Bill Buzbee <buzbee@google.com> |
Introduce "just interpret" chainable pseudo-translation. This is the first step towards enabling translation & self-cosim stress modes. When trace selection begins, the trace head address is pinned and remains in a limbo state until the translation is complete. Previously, if the trace selected aborted for any reason, the trace head would remain forever in limbo. This was not a correctness problem, but caused some small performance anomolies and made life more difficult for self-cosimulation mode. This CL introduces a pseudo-translation that simply routes control to the interpreter. When we detect that a trace selection attempt has failed, the trace head is associated with this fully-chainable pseudo-translation. This also has the benefit for self-cosimulation that we are guaranteed forward progress.
|