summaryrefslogtreecommitdiffstats
path: root/runtime/debugger.cc
Commit message (Collapse)AuthorAgeFilesLines
* JDWP: update handling of 8-bit and 16-bit fieldsSebastien Hertz2015-06-121-49/+121
| | | | | | | | | | | | | We must use special getter/setter for types smaller than int: boolean, byte, char and short. However, JDWP still requires to treat: - int and float as 32-bit values - long and double as 64-bit values Bug: 21746739 (cherry picked from commit 05c26b30843dd8283c703356e75d51726e8b8e3a) Change-Id: I2d667291974e191f2c9b10311ce02435b902dd0c
* JDWP: asynchronous invoke command handlingSebastien Hertz2015-06-121-96/+173
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The JDWP thread used to wait for the result of a method invocation running in an event thread. But doing that prevents the JDWP thread from processing incoming commands from the debugger if the event thread gets suspended by a debug event occurring in another thread. In Android Studio (or another IDE), this leads to the debugger being blocked (with the famous message "Waiting until last debugger command completes" of Android Studio / IntelliJ) because it is actually waiting for the reply of its latest command while the JDWP thread cannot process it. This CL changes the way invoke commands (ClassType.InvokeCommand, ClassType.NewInstance and ObjectReference.InvokeCommand) are handled in the ART runtime. The JDWP thread no longer waits for the event thread to complete the method invocation. It now simply waits for the next JDWP command to process. This means it does not send any reply for invoke commands, except if the information given by the debugger is wrong. In this case, it still sends a reply with the appropriate error code. The event thread is now responsible for sending the reply (containing the result and the exception object of the invoked method) before going back to the suspended state. In other words, we add special handling for invoke commands so they are handled asynchronously while other commands remained handled synchronously. In the future, we may want to handle all commands asynchronously (using a queue of reply/event for instance) to remove the special handling code this CL is adding. Now the JDWP thread can process commands while a thread is invoking a method, it is possible for the debugger to detach (by sending a VirtualMachine.Dispose command) before the invocation completes. In that situation, we must not suspend threads again (including the event thread that executed the method) because they would all remain suspended forever. Also minor cleanup of the use of JDWP constants and update comments. Bug: 21515842 Bug: 18899981 (cherry picked from commit cbc5064ff05179b97b416f00ca579c55e38cd7d9) Change-Id: I8d31006043468913ee8453212e6d16e11fcfe4ea
* Move mirror::ArtMethod to nativeMathieu Chartier2015-06-021-108/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Optimizing + quick tests are passing, devices boot. TODO: Test and fix bugs in mips64. Saves 16 bytes per most ArtMethod, 7.5MB reduction in system PSS. Some of the savings are from removal of virtual methods and direct methods object arrays. Bug: 19264997 (cherry picked from commit e401d146407d61eeb99f8d6176b2ac13c4df1e33) Change-Id: I622469a0cfa0e7082a2119f3d6a9491eb61e3f3d Fix some ArtMethod related bugs Added root visiting for runtime methods, not currently required since the GcRoots in these methods are null. Added missing GetInterfaceMethodIfProxy in GetMethodLine, fixes --trace run-tests 005, 044. Fixed optimizing compiler bug where we used a normal stack location instead of double on ARM64, this fixes the debuggable tests. TODO: Fix JDWP tests. Bug: 19264997 Change-Id: I7c55f69c61d1b45351fd0dc7185ffe5efad82bd3 ART: Fix casts for 64-bit pointers on 32-bit compiler. Bug: 19264997 Change-Id: Ief45cdd4bae5a43fc8bfdfa7cf744e2c57529457 Fix JDWP tests after ArtMethod change Fixes Throwable::GetStackDepth for exception event detection after internal stack trace representation change. Adds missing ArtMethod::GetInterfaceMethodIfProxy call in case of proxy method. Bug: 19264997 Change-Id: I363e293796848c3ec491c963813f62d868da44d2 Fix accidental IMT and root marking regression Was always using the conflict trampoline. Also included fix for regression in GC time caused by extra roots. Most of the regression was IMT. Fixed bug in DumpGcPerformanceInfo where we would get SIGABRT due to detached thread. EvaluateAndApplyChanges: From ~2500 -> ~1980 GC time: 8.2s -> 7.2s due to 1s less of MarkConcurrentRoots Bug: 19264997 Change-Id: I4333e80a8268c2ed1284f87f25b9f113d4f2c7e0 Fix bogus image test assert Previously we were comparing the size of the non moving space to size of the image file. Now we properly compare the size of the image space against the size of the image file. Bug: 19264997 Change-Id: I7359f1f73ae3df60c5147245935a24431c04808a [MIPS64] Fix art_quick_invoke_stub argument offsets. ArtMethod reference's size got bigger, so we need to move other args and leave enough space for ArtMethod* and 'this' pointer. This fixes mips64 boot. Bug: 19264997 Change-Id: I47198d5f39a4caab30b3b77479d5eedaad5006ab
* Fix single-step in native threadSebastien Hertz2015-05-281-1/+3
| | | | | | | | | | | | If we attempt to single-step in a thread that is not running Java code, there is no current method on the stack. So we need to check for null before trying to decode debug info. Bug: 21320157 (cherry picked from commit 52f5f93873ec244320e05b033243c5c7a3ae40e2) Change-Id: I961108071dd58a23f6327370b00c35a4cabe0aa7
* ART: Clean up arm64 kNumberOfXRegisters usage.Vladimir Marko2015-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | Avoid undefined behavior for arm64 stemming from 1u << 32 in loops with upper bound kNumberOfXRegisters. Create iterators for enumerating bits in an integer either from high to low or from low to high and use them for <arch>Context::FillCalleeSaves() on all architectures. Refactor runtime/utils.{h,cc} by moving all bit-fiddling functions to runtime/base/bit_utils.{h,cc} (together with the new bit iterators) and all time-related functions to runtime/base/time_utils.{h,cc}. Improve test coverage and fix some corner cases for the bit-fiddling functions. Bug: 13925192 (cherry picked from commit 80afd02024d20e60b197d3adfbb43cc303cf29e0) Change-Id: I905257a21de90b5860ebe1e39563758f721eab82
* JDWP: fix breakpoint on catch statementSebastien Hertz2015-05-261-0/+20
| | | | | | | | | | | | | | | | | | | Setting a breakpoint on a catch statement in the source actually installs the breakpoint on a DEX move-exception instruction. At this point, an exception is pending in the current thread. The issue is no exception must be pending in the current thread to report the breakpoint event. This is required to be able to call JNI functions to create JDWP ids. This CL fixes it by clearing the pending exception before reporting event and restore it after reporting the event. Bug: 21382373 (cherry picked from commit de48aa6708a3d5dacf7db3d64965e23261fb15d3) Change-Id: Ie107eb47b6f2559c4fa5297f4033e07baad06f38
* Intercept JNI invocation of String.<init> methods.Jeff Hao2015-05-201-1/+2
| | | | | | | | | | | libmono uses JNI AllocObject and CallNonvirtualVoidMethod to create and initialize a string instead of using the recommended NewObject. This change adds an intercept to change the String.<init> call to a StringFactory call instead. Then, it uses the object id of the original string object referrer and maps it to the result of the StringFactory. Bug: 21288130 Change-Id: Ib4db402c178bc37188d5c5faf30b6e4fdc747b17
* JDWP: more GC safetySebastien Hertz2015-05-181-4/+5
| | | | | | | | | | | | Ensures GC safety when keeping references that may be moved by GC: - SingleStepControl: stores ArtMethod* in a GcRoot - ModBasket: stores references in a StackHandleScope Bug: 18166750 (cherry picked from commit 261bc044a3575512869586593e99e97cd8b1c321) Change-Id: I35971a901537956739d1f089d61cb4ea9dc6c93d
* Hold heap bitmap lock in Heap::GetObjectsAllocatedMathieu Chartier2015-05-121-0/+1
| | | | | | | | | | | Fixes a race condition where add and remove space could cause a crash when we iterated over the spaces. TODO: Add a spaces lock or something to guard against this. Bug: 21031927 Change-Id: I7f0d558316f8e9d9f22ffd182e8666355bf50d47
* Add a flag to StackVisitor for inlining.Nicolas Geoffray2015-05-111-11/+25
| | | | | | | | | The flag tells whether the stack walk needs to include inlined Java frames. This does not do anything just yet, as we're not inlining anyways. Change-Id: I716e25094fe56fa335ca1f9a398c1bcdba478e73
* Merge "Support multiple instrumentation clients"Sebastien Hertz2015-05-071-3/+6
|\
| * Support multiple instrumentation clientsSebastien Hertz2015-05-071-3/+6
| | | | | | | | | | | | | | | | | | | | | | Changes Instrumentation::ConfigureStubs to support multiple clients that need different levels of instrumenation. A client is identified by a string key used to save the desired instrumentation level. Also adds regression gtest instrumentation_test and some cleanup. Bug: 19829329 Change-Id: I1fc24a86fcb7cb46d4be806895376c25cc0a0b3c
* | JDWP: properly combine location eventsSebastien Hertz2015-04-291-10/+66
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL properly groups JDWP events at the same location: Breakpoint, Single-step, Method Entry and Method Exit. This is necessary if the debugger is not the only instrumentation listener. This matches the behavior of Dalvik, especially for methods with a single return instruction. The interpreter was tuned so the instrumentation callbacks were called to satisfy the debugger with the idea the debugger was the only instrumentation listener. This is not true when method tracing is enabled at the same time. When tracing is enabled, there is always a listener for MethodEntry and MethodExit events (art::Trace class). However, if the debugger is only listening to DexPcMoved event (to manage JDWP Breakpoint event), it will not be notified of this event. We now properly call all the instrumentation callbacks in the interpreter and move the logic specific to debugging into the class DebugInstrumentationListener. This allows to properly group JDWP location events together depending on the sequence of instrumentation callbacks. We add Thread::tls_32bit_sized_values::debug_method_entry_ flag to remember we just entered a method. It replaces the local variable notified_method_entry_event in the interpreter and simplifies the code. Bump oat version to force recompilation because the layout of the Thread class is modified. Bug: 19829329 Change-Id: I204af9112e37d2eebc86661fb7c961a41c74e598
* Merge "Replace String CharArray with internal uint16_t array."Jeff Hao2015-04-281-1/+1
|\
| * Replace String CharArray with internal uint16_t array.Jeff Hao2015-04-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Summary of high level changes: - Adds compiler inliner support to identify string init methods - Adds compiler support (quick & optimizing) with new invoke code path that calls method off the thread pointer - Adds thread entrypoints for all string init methods - Adds map to verifier to log when receiver of string init has been copied to other registers. used by compiler and interpreter Change-Id: I797b992a8feb566f9ad73060011ab6f51eb7ce01
* | Fix mismatched malloc/free delete/new.Christopher Ferris2015-04-271-1/+1
|/ | | | | | | | | | | | | | | Modify the monitor code to override the delete operator. The problem is the new operator is overloaded to return a pointer returned by posix_memalign, but then it's freed with a delete, not a free call. Also, fix the debugger code to use the [] for a std::unique_ptr to match how the value is actually allocated. Both problems found by ASAN. Bug: 18202869 Change-Id: I2f3a2c02a7f35399b7ba6717b08a035089fab00d
* Replace NULL with nullptrMathieu Chartier2015-04-221-9/+10
| | | | | | | Also fixed some lines that were too long, and a few other minor details. Change-Id: I6efba5fb6e03eb5d0a300fddb2a75bf8e2f175cb
* Merge "JDWP: fix thread_list deadlock"Sebastien Hertz2015-04-131-82/+48
|\
| * JDWP: fix thread_list deadlockSebastien Hertz2015-04-081-82/+48
| | | | | | | | | | | | | | | | | | Limits the scope of Locks::thread_list_lock_ locking in the debugger so we do not try to lock it twice when creating a JDWP id (because calling Object::IdentityHashCode may need to take the lock). Bug: 20048099 Change-Id: I305dd72ccc4d2d007d1603b0d52bcfa94b6842a7
* | Move ArtField to nativeMathieu Chartier2015-04-101-29/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add linear alloc. Moved ArtField to be native object. Changed image writer to put ArtFields after the mirror section. Savings: 2MB on low ram devices 4MB on normal devices Total PSS measurements before (normal N5, 95s after shell start): Image size: 7729152 bytes 23112 kB: .NonMoving 23212 kB: .NonMoving 22868 kB: .NonMoving 23072 kB: .NonMoving 22836 kB: .NonMoving 19618 kB: .Zygote 19850 kB: .Zygote 19623 kB: .Zygote 19924 kB: .Zygote 19612 kB: .Zygote Avg: 42745.4 kB After: Image size: 7462912 bytes 17440 kB: .NonMoving 16776 kB: .NonMoving 16804 kB: .NonMoving 17812 kB: .NonMoving 16820 kB: .NonMoving 18788 kB: .Zygote 18856 kB: .Zygote 19064 kB: .Zygote 18841 kB: .Zygote 18629 kB: .Zygote 3499 kB: .LinearAlloc 3408 kB: .LinearAlloc 3424 kB: .LinearAlloc 3600 kB: .LinearAlloc 3436 kB: .LinearAlloc Avg: 39439.4 kB No reflection performance changes. Bug: 19264997 Bug: 17643507 Change-Id: I10c73a37913332080aeb978c7c94713bdfe4fe1c
* | Merge "Fix JDWP race at runtime shutdown"Sebastien Hertz2015-04-081-10/+2
|\ \
| * | Fix JDWP race at runtime shutdownSebastien Hertz2015-04-011-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the runtime shuts down, it closes the JDWP connection with the debugger. However, if a JDWP command is still being processed by the JDWP handler thread when we close the connection, we won't be able to send its reply. Bug: 19628620 Change-Id: I20301325a347d66f3b9ef95ebe8f156abafb1f76
* | | Merge "JDWP: clear exception when allocation fails"Sebastien Hertz2015-04-071-10/+39
|\ \ \ | |_|/ |/| |
| * | JDWP: clear exception when allocation failsSebastien Hertz2015-04-021-10/+39
| |/ | | | | | | | | | | | | | | | | | | | | Clears pending exception if an allocation (requested by the debugger) fails and logs an error message about the failure. Checks we never leave a pending exception after processing a JDWP request. Bug: 20037531 Change-Id: I63239034a3c1ab368b0e19c2f5f756d9e2ec6a29
* / Refactor and improve GC root handlingMathieu Chartier2015-04-061-8/+6
|/ | | | | | | | | | | | | | | | | | | | | | Changed GcRoot to use compressed references. Changed root visiting to use virtual functions instead of function pointers. Changed root visting interface to be an array of roots instead of a single root at a time. Added buffered root marking helper to avoid dispatch overhead. Root marking seems a bit faster on EvaluateAndApplyChanges due to batch marking. Pause times unaffected. Mips64 is untested but might work, maybe. Before: MarkConcurrentRoots: Sum: 67.678ms 99% C.I. 2us-664.999us Avg: 161.138us Max: 671us After: MarkConcurrentRoots: Sum: 54.806ms 99% C.I. 2us-499.986us Avg: 136.333us Max: 602us Bug: 19264997 Change-Id: I0a71ebb5928f205b9b3f7945b25db6489d5657ca
* Merge "JDWP: more checking for StackFrame commands"Sebastien Hertz2015-03-301-96/+117
|\
| * JDWP: more checking for StackFrame commandsSebastien Hertz2015-03-271-96/+117
| | | | | | | | | | | | | | | | | | | | Checks thread is suspended and the slot is valid for GetValues and SetValues command. Also improves error messages when we could not get or set a local value in the stack or we try to read an invalid reference from the stack. Bug: 15680615 Change-Id: I629099fc908e733edb712bd43e141695ed858f4f
* | Add AccessibleObject and Field to mirrorMathieu Chartier2015-03-291-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Main motivation is to remove all the functionality / field access on java side to ArtField. Also comes with some reflection speedups / slowdowns. Summary results: getDeclaredField/getField are slower mostly due to JNI overhead. However, there is a large speedup in getInt, setInt, GetInstanceField, and GetStaticField. Before timings (N5 --compiler-filter=everything): benchmark ns linear runtime Class_getDeclaredField 782.86 === Class_getField 832.77 === Field_getInt 160.17 = Field_setInt 195.88 = GetInstanceField 3214.38 ============== GetStaticField 6809.49 ============================== After: Class_getDeclaredField 1068.15 ============ Class_getField 1180.00 ============== Field_getInt 121.85 = Field_setInt 139.98 = GetInstanceField 1986.15 ======================= GetStaticField 2523.63 ============================== Bug: 19264997 Change-Id: Ic0d0fc1b56b95cd6d60f8e76f19caeaa23045c77
* Fix ClassLinker::MayBeCalledWithDirectCodePointer for JITMathieu Chartier2015-03-261-0/+5
| | | | | | | | | | | | | Currently, we don't know if another method has a direct code pointer or not. This should fix the case where breakpoints occasionally don't work with JIT. The JIT now also checks that a method doesn't have any breakpoints before starting to compile it. Bug: 17950037 Change-Id: I17cfe874fe4825beba23903a5053d5cb27e106cb
* JDWP: Optimized single step during debuggingDaniel Mihalyi2015-03-241-33/+122
| | | | | | | | | | | | | | | | | | | | | | | For single stepping full deoptimization and undeoptimizations were performed with significant overhead, because every code will be executed in interpreted mode during a single step, even if it is not strictly required. For example, if we have a computation heavy method call and we would like to step over it, that method (and all the methods called from it) will run in interpreter mode. This can take so long in some cases (e.g. multiple minutes) that it makes debugging process unusable. The solution for this limitation is not using full deoptimizations for single steps and force interpreter only for those methods that we are about to step into, and require stack deoptimization before step outs. Bug: 17750566 Bug: 18094282 Bug: https://code.google.com/p/android/issues/detail?id=77984 Change-Id: I683c52465883146c4c84ec47bf96f8efd920527f Signed-off-by: Daniel Mihalyi <daniel.mihalyi@mattakis.com>
* Add more info to who called SuspendAllMathieu Chartier2015-03-131-6/+6
| | | | | | Helps diagnose related jank. Change-Id: I38191cdda723c6f0355d0197c494a3dff2b6653c
* Remove ThrowLocation.Nicolas Geoffray2015-03-101-1/+0
| | | | | | | Note that this is a cleanup change, and has no functionality change. The ThrowLocation had no use anymore. Change-Id: I3d2126af1dc673cec3a0453ff3d56a172663a5f6
* JDWP: allocate DebugInvokeReq only when requestedSebastien Hertz2015-03-091-76/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only allocates thread-local DebugInvokeReq when the debugger requests a thread to invoke a method. The JDWP thread allocates that structure then attaches it to the target thread. When the thread is resumed, it executes the method. Once the invocation completes, the thread detaches the DebugInvokeReq, signals the JDWP thread then suspends. Finally, the JDWP thread wakes up, prepares the reply with the invoke result (or exception) and deallocates the DebugInvokeReq. Also ensures GC safety for object returned by the invoke. We add the object to the JDWP object registry right after the invoke. We now reference that object with a JDWP ObjectID instead of an Object* in the DebugInvokeReq struct. This prevent from accessing a stale reference if the GC runs and moves the Object*. This CL includes the following changes: - Move former DebugInvokeReq::ready flag to Thread::tls_32bit_sized_values::ready_for_debug_invoke. It's needed to know whether a thread has been suspended by an event, thus ready to invoke a method from the debugger. - Remove DebugInvokeReq::invoke_needed: we now test if we attached a DebugInvokeReq* to the thread. - Rename misleading FinishMethod function to RequestMethod. Bug: 19142632 Bug: 18166750 Change-Id: I351fb4eb94bfe69fcafb544d21d55ff35a033000
* Compute the right catch location for the debugger.Nicolas Geoffray2015-03-091-23/+104
| | | | | | Also remove tls ThrowLocation, it is not needed anymore. Change-Id: I78fddf09ce968ca475e39c17fa76d699c589c8d9
* Change how we report exceptions to the debugger.Nicolas Geoffray2015-03-031-3/+0
| | | | | | | This is only a refactoring/cleanup. Bug fixes with respect to catch location, and more cleanups will follow. Change-Id: I30d3c6260b0c8f8115a811621397225b88f2063a
* Revert "Revert "Add JIT""Mathieu Chartier2015-02-241-0/+7
| | | | | | | | Added missing EntryPointToCodePointer. This reverts commit a5ca888d715cd0c6c421313211caa1928be3e399. Change-Id: Ia74df0ef3a7babbdcb0466fd24da28e304e3f5af
* Merge "JDWP: update thread synchronization"Sebastien Hertz2015-02-241-2/+11
|\
| * JDWP: update thread synchronizationSebastien Hertz2015-02-061-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This CL ensures only one thread can do JDWP stuff at a time: either processing a command coming from the debugger (JDWP thread) or sending an event (breakpoint, class prepare, etc) to the debugger before suspending. The JDWP thread now uses AcquireJdwpTokenForCommand and ReleaseJdwpTokenForCommand, respectively acquiring and releasing the token used for synchronization. On the other hand, the event threads now use AcquireJdwpTokenForEvent and ReleaseJdwpTokenForEvent. During an invoke, the target thread needs to take the JDWP token to execute the method while it's already held by the JDWP handler thread waiting for the invocation to complete. To avoid both threads from waiting for each other (deadlock), the JDWP thread releases the token and acquires it again after the invocation is complete, so the target thread can run safely and prevents other threads from sending events. Bug: 19120467 Change-Id: Ie3208fb940a60573769d494128cf22f0fa30fa61
* | Revert "Add JIT"Nicolas Geoffray2015-02-241-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sorry, run-test crashes on target: 0-05 12:15:51.633 I/DEBUG (27995): Abort message: 'art/runtime/mirror/art_method.cc:349] Check failed: PcIsWithinQuickCode(reinterpret_cast<uintptr_t>(code), pc) java.lang.Throwable java.lang.Throwable.fillInStackTrace() pc=71e3366b code=0x71e3362d size=ad000000' 10-05 12:15:51.633 I/DEBUG (27995): r0 00000000 r1 0000542b r2 00000006 r3 00000000 10-05 12:15:51.633 I/DEBUG (27995): r4 00000006 r5 b6f9addc r6 00000002 r7 0000010c 10-05 12:15:51.633 I/DEBUG (27995): r8 b63fe1e8 r9 be8e1418 sl b6427400 fp b63fcce0 10-05 12:15:51.633 I/DEBUG (27995): ip 0000542b sp be8e1358 lr b6e9a27b pc b6e9c280 cpsr 40070010 10-05 12:15:51.633 I/DEBUG (27995): Bug: 17950037 This reverts commit 2535abe7d1fcdd0e6aca782b1f1932a703ed50a4. Change-Id: I6f88849bc6f2befed0c0aaa0b7b2a08c967a83c3
* | Add JITMathieu Chartier2015-02-231-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently disabled by default unless -Xjit is passed in. The proposed JIT is a method JIT which works by utilizing interpreter instrumentation to request compilation of hot methods async during runtime. JIT options: -Xjit / -Xnojit -Xjitcodecachesize:N -Xjitthreshold:integervalue The JIT has a shared copy of a compiler driver which is accessed by worker threads to compile individual methods. Added JIT code cache and data cache, currently sized at 2 MB capacity by default. Most apps will only fill a small fraction of this cache however. Added support to the compiler for compiling interpreter quickened byte codes. Added test target ART_TEST_JIT=TRUE and --jit for run-test. TODO: Clean up code cache. Delete compiled methods after they are added to code cache. Add more optimizations related to runtime checks e.g. direct pointers for invokes. Add method recompilation. Move instrumentation to DexFile to improve performance and reduce memory usage. Bug: 17950037 Change-Id: Ifa5b2684a2d5059ec5a5210733900aafa3c51bca
* | Follow up 129144Sebastien Hertz2015-02-171-4/+11
|/ | | | | | | | | | Passes JDWP options to debugger on runtime init so we no longer need to keep them on the heap. Updates ParseJdwpOption to return Result for consistency. Bug: 19275792 Change-Id: I68b7e58908164d3e4cf9e3fbcc3dfab6ce0579a5
* Read JDWP options from runtimeSebastien Hertz2015-02-051-113/+4
| | | | | | | | | | | | Allocates JDWP::JdwpOptions on the heap and copies parsed options to avoid the need to include jdwp/jdwp.h into runtime.h file. Also does some minor cleanup and removes the old JDWP options parsing code that became dead code after we move it to the new command-line parser. Bug: 19275792 Change-Id: I71901c89fbf2cc3c1901a089e2a98b4326c6ee70
* Check for null class of classMathieu Chartier2015-01-311-0/+4
| | | | | | | | | | Experimental fix. Bug: 19193521 (cherry picked from commit 65370e37b3fd9e53e3c1bce5757912e8309cd305) Change-Id: If59fe9a7bd16f3578ed036a5dbb2787862b33766
* JDWP: allocate single step control only when activeSebastien Hertz2015-01-261-66/+47
| | | | | | | | Only allocates SingleStepControl when a single step is requested in a thread. Bug: 19142632 Change-Id: I830b7eaea86b516d3fac80ce14d41c66b4bd5415
* More of the concurrent copying collector.Hiroshi Yamauchi2015-01-231-0/+12
| | | | | Bug: 12687968 Change-Id: I62f70274d47df6d6cab714df95c518b750ce3105
* Fix compaction bugs related to IdentityHashCodeMathieu Chartier2015-01-231-6/+5
| | | | | | IdentityHashCode is a suspend point if monitor inflation occurs. Change-Id: I114021aed8b3f3437109ef622298de05e13b4e34
* Clean up the locks around Heap::VisitObjects().Hiroshi Yamauchi2015-01-201-0/+1
| | | | | | | | This is so that we could support suspending all threads when visiting objects in the presence of a concurrent, moving collector. Bug: 12687968 Change-Id: Icc8e60630465afde948ebc6ea91d4ebaff5d7837
* Print more info in MarkSweep::VerifyRootMathieu Chartier2015-01-151-9/+7
| | | | | | | | | | | | | | | | | | | | | | | Refactored old root callback to use a new class called RootInfo. RootInfo contains all the relevant info related to the root associated with the callback. The MarkSweep::VerifyRoot function now uses this info to print the StackVisitor's described location if the GC root is of the type kRootJavaFrame. Some other cleanup. Example output: E/art (12167): Tried to mark 0x123 not contained by any spaces E/art (12167): Attempting see if it's a bad root E/art (12167): Found invalid root: 0x123 with type RootJavaFrame E/art (12167): Location=Visiting method 'void java.lang.Runtime.gc()' at dex PC 0xffffffff (native PC 0x0) vreg=0 (cherry picked from commit 12f7423a2bb4bfab76700d84eb6d4338d211983a) Bug: 18588862 Change-Id: Ic5a2781f704e931265ffb3621c2eab4b2e25f60f
* JDWP: fix deadlock with GCSebastien Hertz2015-01-131-2/+7
| | | | | | | | | | | | | | | | | | | | This CL fixes a deadlock where JDWP thread and running GC thread are waiting for each other. Here is the sequence of the deadlock: 1. GC thread disables access to weak global references, then releases mutator lock. 2. JDWP thread takes mutator lock exclusively after suspending all threads. 3. GC thread waits for shared mutator lock which is held by JDWP thread. 4. JDWP thread clears weak global references but need to wait for GC thread to re-enable access to them. To avoid that situation, we ensure the JDWP thread does not attempt to delete weak global references while holding the mutator exclusively so GC thread is not blocked. Bug: 18995321 Change-Id: Ia7e82f463c27ffdcfd730c3117337a6a33d111e7
* Change hprof to use streamingMathieu Chartier2015-01-091-0/+4
| | | | | | | | | | | | | | | Previously, we compute the whole hprof dump in memory resulting in > 50MB of memory usage for some apps (such as maps). This could cause the app to get killed by the low memory killer. The solution works by doing the dump in 2 passes. The first pass calculates the size of the dump. The second pass starts by sending the DDMS header with the correct size, then does the rest of the hprof dump by streaming and sending data one HprofRecord at a time. Bug: 18921793 Change-Id: I7dd9f5cfe49799ba268095c994a8c2eb1fe493df
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-23 17:09:19 +0000