375fb116bcb817b37509ab579dbd55cdbb765cbf |
|
15-Jun-2011 |
Carl Shapiro <cshapiro@google.com> |
Normalize the include guard style. An leading underscore followed by a capital letter is a reserved name space in C and C++. This change also moves any #include directives within the include guard in some of the compiler/codegen/arm header files. Change-Id: I9715e2c5301699d31886e61d0fe6e29483555a2a
|
d862faa2ceae186da5518607505eb942d634ced9 |
|
28-Apr-2011 |
Carl Shapiro <cshapiro@google.com> |
Get rid of uneeded extern, enum, typedef and struct qualifiers. Change-Id: I236c5a1553a51f82c9bc3eaaab042046c854d3b4
|
ae188c676c681e47a93ade7fdf0144099b470e03 |
|
08-Apr-2011 |
Carl Shapiro <cshapiro@google.com> |
Compile the garbage collector and heap profiler as C++. Change-Id: I25d8fa821987a3dd6d7109d07fd42dbf2fe0e589
|
9a3147c7412f4794434b4c2604aa2ba784867774 |
|
03-Mar-2011 |
buzbee <buzbee@google.com> |
Interpreter restructuring This is a restructuring of the Dalvik ARM and x86 interpreters: o Combine the old portstd and portdbg interpreters into a single portable interpreter. o Add debug/profiling support to the fast (mterp) interpreters. o Delete old mechansim of switching between interpreters. Now, once you choose an interpreter at startup, you stick with it. o Allow JIT to co-exist with profiling & debugging (necessary for first-class support of debugging with the JIT active). o Adds single-step capability to the fast assembly interpreters without slowing them down (and, in fact, measurably improves their performance). o Remove old "polling for safe point" mechanism. Breakouts now achieved via modifying base of interpreter handler table. o Simplify interpeter control mechanism. o Allow thread-granularity control for profiling & debugging The primary motivation behind this change was to improve the responsiveness of debugging and profiling and to make it easier to add new debugging and profiling capabilities in the future. Instead of always bailing out to the slow debug portable interpreter, we can now stay in the fast interpreter. A nice side effect of the change is that the fast interpreters got a healthy speed boost because we were able to replace the polling safepoint check that involved a dozen or so instructions with a single table-base reload. When combined with the two earlier CLs related to this restructuring, we show a 5.6% performance improvement using libdvm_interp.so on the Checkers benchmark relative to Honeycomb. Change-Id: I8d37e866b3618def4e582fc73f1cf69ffe428f3c
|
0970976b0e980be00424f93a69c2bc13ca3131f3 |
|
18-Mar-2011 |
Andy McFadden <fadden@android.com> |
Fix up some JDWP stuff Notably: - Claim to know about synthetic attributes (canGetSyntheticAttribute). Set an appropriate flag in the access flags of fields and methods. (Makes no difference that I can see in Eclipse.) - Stop making copies of descriptor strings. That ceased to be necessary after they were normalized in DEX (pre-1.0). - Correct object type determination, especially w.r.t. the specially- tagged types (strings, threads, classloaders, etc). - Handle a FIELD_ONLY mod (not tested). - Added a bit of debugging stuff. Change-Id: I5651b5b76d904a9edbd051e039423795faaa1650
|
cb3081f675109049e63380170b60871e8275f9a8 |
|
14-Jan-2011 |
buzbee <buzbee@google.com> |
Consolidate mterp's debug/profile/suspend control This is a step towards full debug & profiling support in JIT'd code. Previously, the interpreter made multiple distinct checks for pending suspend requests, debugger and profiler checks at each safe point. This CL moves the individual controls into a single control word, significantly speeding up the safe-point check code path in the common fast case. In short, any time some VM component wants control to break at a safe point it will set a bit in gDvm.interpBreak, which will be examined at the safe point check in footer.S. In the old code, the safe point check consisted of 11 instructions (including 6 loads). The new sequence is 6 instructions (4 loads - two of which are needed and two are speculative to fill otherwise stalling slots). This code path is hot enough in the interpreter that we actually see some measureable speedups in benchmarks. The old sieve benchmark improves from 252 to 256 (~1.5%). As part of the change, global debuggerActive and activeProfilers variables have been eliminated as redundant. Note also that there is a subtle change in thread suspension. Thread suspend request counts are kept on a per-thread basis, and previously each thread would only examine its own suspend count. With this change, a bit has been allocated in interpBreak to signify that at least one suspend request is active across all threads. This bit is treated as "some thread is supposed to suspend, check to see if it's me". Change-Id: I527dc918f58d1486ef3324136080ef541a775ba8
|
884cd427f504a6e105059199c3eeadd51a8b9c6e |
|
19-Jul-2010 |
Andy McFadden <fadden@android.com> |
Implement JDWP ArrayType.NewInstance. With this, you can go into the Eclipse "Display" view and evaluate "new byte[5]" to get "(byte[]) [0, 0, 0, 0, 0]". Change-Id: Id110c5701a9de12222760be6623585b5f7e28023
|
0171812e59e2520a4345b9bbadd4f7afa0a1de16 |
|
23-Jan-2010 |
Andy McFadden <fadden@android.com> |
Add streaming method profiling support. The goal is to allow DDMS to start/stop method profiling in apps that don't have permission to write to /sdcard. Instead of writing the profiling data to disk and then pulling it off, we just blast the whole thing straight from memory. This includes: - New method tracing start call (startMethodTracingDdms). - Rearrangement of existing VMDebug method tracing calls for sanity. - Addition of "vector" chunk send function, with corresponding update to the JDWP transport function. - Reshuffled the method trace start interlock, which seemed racy. - Post new method-trace-profiling-streaming feature to DDMS. Also: - Added an internal exception-throw function that allows a printf format string, so we can put useful detail into exception messages. For bug 2160407.
|
c6e64ea32a7732e98975e37c5f8545c652a41ac8 |
|
05-Dec-2009 |
Andy McFadden <fadden@android.com> |
Don't assume debugger wants all exceptions. The JDWP implementation in the VM keeps a list of the objects that the debugger knows about, and prevents the GC from collecting them (which isn't strictly necessary, but it's a whole lot easier than doing it right). Because of the way it's implemented, it actually ended up keeping track of all thrown exceptions, even if the debugger wasn't interested in hearing about them. With this change we now do a "late" registration of the exception object, preventing exception-happy code from filling memory when the debugger is attached.
|
96516932f1557d8f48a8b2dbbb885af01a11ef6e |
|
29-Oct-2009 |
Andy McFadden <fadden@android.com> |
Change the way breakpoints work. This replaces the breakpoint mechanism with a more efficient approach. We now insert breakpoint instructions into the bytecode stream instead of maintaining a table. This requires mapping DEX files as private instead of shared, which allows copy-on-write to work. mprotect() is used to guard the pages against inadvertent writes. Unused opcode EC is now OP_BREAKPOINT. It's not recognized by dexdump or any interpreter except portdbg, but it can be encountered by the bytecode verifier (the debugger can request breakpoints in unverified code). Breakpoint changes are blocked while the verifier runs to avoid races. This eliminates method->debugBreakpointCount, which is no longer needed. (Also, it clashed with LinearAlloc's read-only mode.) The deferred verification error mechanism was using a code-copying approach to modify the bytecode stream. That has been changed to use the same copy-on-write modification mechanism. Also, normalized all PAGE_SIZE/PAGESIZE references to a single SYSTEM_PAGE_SIZE define. Simple Fibonacci computation test times (opal-eng): JIT, no debugger: 10.6ms Fast interp, no debugger: 36ms Portable interp, no debugger: 43.8ms ORIG debug interp, no breakpoints set: 458ms ORIG debug interp, breakpoint set nearby: 697ms NEW debug interp, no breakpoints set: 341ms NEW debug interp, breakpoints set nearby: 341ms Where "nearby" means there's a breakpoint in the method doing the computation that isn't actually hit -- the VM had an optimization where it flagged methods with breakpoints and skipped some of the processing when possible. The bottom line is that code should run noticeably faster while a debugger is attached.
|
6ff3c8fde9623dadad726dbd5e1658585c321751 |
|
13-Oct-2009 |
Andy McFadden <fadden@android.com> |
Add JDWP ReferenceType.ClassObject handler. For bug 2157236.
|
f50c6d57afb09f8ed9da179a8bc8b409279ef8a6 |
|
03-Oct-2009 |
Andy McFadden <fadden@android.com> |
Add implementation of JDWP ClassType.NewInstance Add a handler for the ClassType.NewInstance request, and some bits of plumbing to go with it. For bug 2157236.
|
f6c387128427e121477c1b32ad35cdcaa5101ba3 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
|
f72d5de56a522ac3be03873bdde26f23a5eeeb3c |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
|
2ad60cfc28e14ee8f0bb038720836a4696c478ad |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
|