| b139b6d3833cd6a90f345204202ec57ff277c088 |
|
01-Mar-2017 |
Hiroshi Yamauchi <yamauchi@google.com> |
Revert "Add jdwp event_list_lock_ to expected_mutexes_on_weak_ref_access_."
This reverts commit 35b456a05af864da6580dd01c033efb0ed3e3e44.
Will be superceded by aog/346324.
Bug: 35360959
Test: test-art-host.
Test: jdwp test.
Change-Id: I325003cb85b29c0245de6ba86b719b51201a840c
|
| 35b456a05af864da6580dd01c033efb0ed3e3e44 |
|
23-Feb-2017 |
Hiroshi Yamauchi <yamauchi@google.com> |
Add jdwp event_list_lock_ to expected_mutexes_on_weak_ref_access_.
To avoid a DCHECK failure where event_list_lock_ is unexpectedly held
during a weak ref access.
Also move event_list_lock to Locks.
Bug: 35360959
Test: test-art-host.
Test: jdwp test.
Change-Id: I6315e1f7152058656f2479ad7b4e4f3defd15555
|
| 5643caf2eeded64fc8b4f2a43bdf6444bb3da77c |
|
08-Feb-2017 |
Alex Light <allight@google.com> |
Remove breakpoints from redefined classes
Test: Manual
Change-Id: If8d9a38635bda7a0d69925b735b6f10055192b34
|
| 46ee31b67d7ee1bd085fbc240502053caa3cf8fa |
|
14-Dec-2016 |
Andreas Gampe <agampe@google.com> |
ART: Move to libbase StringPrintf
Remove ART's StringPrintf implementation. Fix up clients. Add
missing includes where necessary.
Test: m test-art-host
Change-Id: I564038d5868595ac3bb88d641af1000cea940e5a
|
| 2b25ca97ff20ab189567391e861dcd14204a1646 |
|
22-Nov-2016 |
Sebastien Hertz <shertz@google.com> |
Fix event reporting from the debugger thread
The debugger thread may trigger events (like CLASS PREPARE after the
initalization of a class while processing a command).
This CL removes the incorrect CHECK that makes the runtime abort in
this case. However, we do check that only the debugger thread can
report an event while it is already processing a command.
Bug: 33032664
Test: art/tools/run-jdwp-tests.sh '--mode=host' '--variant=X64'
(cherry picked from commit af8bcf83535cd7bf5651ada2fb08a0ba9c5191d6)
Change-Id: Id2e4362393203935e820586560800b300c6dd3a3
|
| af8bcf83535cd7bf5651ada2fb08a0ba9c5191d6 |
|
22-Nov-2016 |
Sebastien Hertz <shertz@google.com> |
Fix event reporting from the debugger thread
The debugger thread may trigger events (like CLASS PREPARE after the
initalization of a class while processing a command).
This CL removes the incorrect CHECK that makes the runtime abort in
this case. However, we do check that only the debugger thread can
report an event while it is already processing a command.
Bug: 33032664
Test: art/tools/run-jdwp-tests.sh '--mode=host' '--variant=X64'
Change-Id: I32a284cfb4df6eb44eac27bbdcabd3c426d726ce
|
| 5c657fe8e3afdce77dc610446f37a43865cff702 |
|
03-Nov-2016 |
Vladimir Marko <vmarko@google.com> |
Pass some arguments by const reference.
Test: Rely on TreeHugger.
Bug: 32619234
Change-Id: Ia26277893641dcb3562eaeacaec4e089a978d56a
|
| 709b070044354d9f47641f273edacaeeb0240ab7 |
|
13-Oct-2016 |
David Sehr <sehr@google.com> |
Remove mirror:: and ArtMethod deps in utils.{h,cc}
The latest chapter in the ongoing saga of attempting to dump a DEX
file without having to start a whole runtime instance. This episode
finds us removing references to ArtMethod/ArtField/mirror.
One aspect of this change that I would like to call out specfically
is that the utils versions of the "Pretty*" functions all were written
to accept nullptr as an argument. I have split these functions up as
follows:
1) an instance method, such as PrettyClass that obviously requires
this != nullptr.
2) a static method, that behaves the same way as the util method, but
calls the instance method if p != nullptr.
This requires using a full class qualifier for the static methods,
which isn't exactly beautiful. I have tried to remove as many cases
as possible where it was clear p != nullptr.
Bug: 22322814
Test: test-art-host
Change-Id: I21adee3614aa697aa580cd1b86b72d9206e1cb24
|
| 0795f23920ee9aabf28e45c63cd592dcccf00216 |
|
28-Sep-2016 |
Mathieu Chartier <mathieuc@google.com> |
Clean up ScopedThreadStateChange to use ObjPtr
Also fixed inclusion of -inl.h files in .h files by adding
scoped_object_access-inl.h and scoped_fast_natvie_object_access-inl.h
Changed AddLocalReference / Decode to use ObjPtr.
Changed libartbenchmark to be debug to avoid linkage errors.
Bug: 31113334
Test: test-art-host
Change-Id: I4d2e160483a29d21e1e0e440585ed328b9811483
|
| bdf7f1c3ab65ccb70f62db5ab31dba060632d458 |
|
31-Aug-2016 |
Andreas Gampe <agampe@google.com> |
ART: SHARED_REQUIRES to REQUIRES_SHARED
This coincides with the actual attribute name and upstream usage.
Preparation for deferring to libbase.
Test: m
Test: m test-art-host
Change-Id: Ia8986b5dfd926ba772bf00b0a35eaf83596d8518
|
| f1d666e1b48f8070ef1177fce156c08827f08eb8 |
|
04-Sep-2015 |
Mathieu Chartier <mathieuc@google.com> |
Add ScopedThreadSuspension
Fixes the TransitionFromRunnableToSuspended and
TransitionFromSuspendedToRunnable pattern that was prone to errors.
Change-Id: Ie6ae9c0357c83b4fc4899d05dfa0975553170267
|
| 90443477f9a0061581c420775ce3b7eeae7468bc |
|
17-Jul-2015 |
Mathieu Chartier <mathieuc@google.com> |
Move to newer clang annotations
Also enable -Wthread-safety-negative.
Changes:
Switch to capabilities and negative capabilities.
Future work:
Use capabilities to implement uninterruptible annotations to work
with AssertNoThreadSuspension.
Bug: 20072211
Change-Id: I42fcbe0300d98a831c89d1eff3ecd5a7e99ebf33
|
| 6ba35b50347aa7418c66c7b046cd164987e95df3 |
|
01-Jun-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: asynchronous invoke command handling
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
|
| cbc5064ff05179b97b416f00ca579c55e38cd7d9 |
|
01-Jun-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: asynchronous invoke command handling
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
Change-Id: I15e00fb068340f3d69dc9225d8d2065246e68c58
|
| 3d21bdf8894e780d349c481e5c9e29fe1556051c |
|
22-Apr-2015 |
Mathieu Chartier <mathieuc@google.com> |
Move mirror::ArtMethod to native
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
|
| e401d146407d61eeb99f8d6176b2ac13c4df1e33 |
|
22-Apr-2015 |
Mathieu Chartier <mathieuc@google.com> |
Move mirror::ArtMethod to native
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
Change-Id: I622469a0cfa0e7082a2119f3d6a9491eb61e3f3d
|
| 6650075fb831379d24cfafc3d56442e742418688 |
|
08-Apr-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: more GC safety
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
|
| 261bc044a3575512869586593e99e97cd8b1c321 |
|
08-Apr-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: more GC safety
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
Change-Id: If2b6f9ecff4cf469b50487fd863319fdfa9b9f37
|
| c3cde2c00bcbe97c9b0c119919500fcbbe824baa |
|
10-Apr-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: properly combine location events
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
Bug: 20205350
(cherry picked from commit 9d6bf69ad3012a9d843268fdd5325b6719b6d5f2)
Change-Id: I204af9112e37d2eebc86661fb7c961a41c74e598
|
| 9d6bf69ad3012a9d843268fdd5325b6719b6d5f2 |
|
10-Apr-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: properly combine location events
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
|
| d3ed9a320a89cb9b91b2361892c043ab7e112717 |
|
10-Apr-2015 |
Mathieu Chartier <mathieuc@google.com> |
Fix DCHECK failures from Class::VisitFieldRoots
We now use GetDeclaringClassUnchecked when marking roots to fix
flaky test failures. Fixed a race condition in root marking where
we could have non zero field array length with a null pointer.
Fixed a race condition where we could be marking roots before
FixupTemporaryDeclaringClass had finished. The solution is to
only do the declaring class CHECK if we are at least resolved.
Fixed JDWP tests by changing FieldId / MethodId to be 64 bits.
Also some cleanup.
Change-Id: Ibac09519860d93c3f68a5cc964bbc91dc10a279a
|
| c785344b87221f5e4e6473e5b762e4e61fe65dcf |
|
27-Mar-2015 |
Mathieu Chartier <mathieuc@google.com> |
Move ArtField to native
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
|
| eb07669e9784ccb41d75df180727e57fc4520e28 |
|
22-Aug-2014 |
Daniel Mihalyi <daniel.mihalyi@mattakis.com> |
JDWP: Optimized single step during debugging
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>
|
| 1558b577907b613864e98f05862543557263e864 |
|
25-Feb-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: allocate DebugInvokeReq only when requested
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
|
| 813b9602dadeabf33439cb0592072744f6241ce5 |
|
24-Feb-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: fix thread state on event suspension
Before suspending event thread, we ensure its state is kSuspended
so the debugger sees it as RUNNING instead of WAIT.
Bug: 19103406
Change-Id: I58b4141a958bf6a3c360f6994967fad0078ea373
|
| 2bf93f48bbb417b358c9e3c77911ea6ec7307c15 |
|
09-Jan-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: update thread synchronization
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
|
| ad466adf38db74a9840659626858196091151a64 |
|
09-Jan-2015 |
Mathieu Chartier <mathieuc@google.com> |
Change hprof to use streaming
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
|
| 107e757bfd32cc27750955e6f392986414bebe75 |
|
18-Dec-2014 |
Sebastien Hertz <shertz@google.com> |
JDWP: do not report start/end events for thread without peer
To report start/end thread events, we need the JDWP id of the thread.
To create a JDWP id, we need its java.lang.Thread peer. In the case
there is no Java peer, we can't report the event.
Follow-up https://android-review.googlesource.com/118548 where the
runtime attaches the current thread without Java peer when shutting
down.
Change-Id: Icc2d50f3d2eedd1e0e3c5a21affd2261aaf7a862
|
| 7d95565c84d91ae5dcec4b89728ada208633de0c |
|
22-Oct-2014 |
Sebastien Hertz <shertz@google.com> |
Cleanup JDWP event matching
* Use std::vector for the event match list.
* Make event reporting methods void since result is never used.
* Use nullptr keyword instead of NULL.
Change-Id: Icd6f47e46cefc2cc63325df00037cd4b6a475259
|
| f2134f684923454e00c8ca7675b431a8538131bc |
|
17-Nov-2014 |
Sebastien Hertz <shertz@google.com> |
JDWP: only deoptimize when it is required
We don't need to deoptimize anything when we forced the use of the
interpreter (-Xint). In this case, no compiled code is executed
(except native methods which are not concerned by deoptimization).
Therefore we even don't need to enable/disable deoptimization support
in instrumentation.
We also don't need to deoptimize a method that hasn't been compiled.
Since it will run with interpreter, there is no point deoptimizing
it. However this method may be inlined in a compiled caller method
so we still need to deoptimize everything in this case.
This CL updates breakpoint support by storing the required kind of
deoptimization for a particular method. There are 3 cases:
- kNothing: the method does not require deoptimization.
- kSelectiveDeoptimization: the method needs to be deoptimized.
- kFullDeoptimization: we must deoptimize everythinig.
When uninstalling a breakpoint, we need to do the reverse operation.
Also fixes the SanityCheckExistingBreakpoints function to control
breakpoints related to the given method only and adds extra verbose
ilogs when choosing the appropriate deoptimization kind.
Includes a partial cherry-pick of commit
87553c9fa1298ffb40127b2bb6413859fd3f79df to use method
ClassLinker::GetOatMethodQuickCodeFor.
Bug: 18407046
(cherry picked from commit f3928794a10516e2ac0ffe2686a10891788d4b9c)
Change-Id: I50853cc5fc5c52650485785a1198d35ea0f7fb8e
|
| f3928794a10516e2ac0ffe2686a10891788d4b9c |
|
17-Nov-2014 |
Sebastien Hertz <shertz@google.com> |
JDWP: only deoptimize when it is required
We don't need to deoptimize anything when we forced the use of the
interpreter (-Xint). In this case, no compiled code is executed
(except native methods which are not concerned by deoptimization).
Therefore we even don't need to enable/disable deoptimization support
in instrumentation.
We also don't need to deoptimize a method that hasn't been compiled.
Since it will run with interpreter, there is no point deoptimizing
it. However this method may be inlined in a compiled caller method
so we still need to deoptimize everything in this case.
This CL updates breakpoint support by storing the required kind of
deoptimization for a particular method. There are 3 cases:
- kNothing: the method does not require deoptimization.
- kSelectiveDeoptimization: the method needs to be deoptimized.
- kFullDeoptimization: we must deoptimize everythinig.
When uninstalling a breakpoint, we need to do the reverse operation.
Also fixes the SanityCheckExistingBreakpoints function to control
breakpoints related to the given method only and adds extra verbose
logs when choosing the appropriate deoptimization kind.
Bug: 18407046
Change-Id: I5212c1fd2f72e06c79e7871db15696824d37dc0b
|
| 277ccbd200ea43590dfc06a93ae184a765327ad0 |
|
04-Nov-2014 |
Andreas Gampe <agampe@google.com> |
ART: More warnings
Enable -Wno-conversion-null, -Wredundant-decls and -Wshadow in general,
and -Wunused-but-set-parameter for GCC builds.
Change-Id: I81bbdd762213444673c65d85edae594a523836e5
|
| c29f896d4f625fee4269bf44c22838700a859c2f |
|
08-Oct-2014 |
Sebastien Hertz <shertz@google.com> |
Only watch location for BREAKPOINT event
This CL ensures we watch a location for BREAKPOINT event only. Other
events (single-step, method entry/exit, ...) are handled differently
and LocationOnly modifier is used as an event filter in this case.
This prevents from failing a check when we need to deoptimize for
non-breakpoint event.
Bug: 17908144
(cherry picked from commit 033aabf9789eda162e183ed34678d665dc903387)
Change-Id: Iaaf2954bcb67d21ae3df5d7ed3dcd86ed27c128a
|
| 033aabf9789eda162e183ed34678d665dc903387 |
|
08-Oct-2014 |
Sebastien Hertz <shertz@google.com> |
Only watch location for BREAKPOINT event
This CL ensures we watch a location for BREAKPOINT event only. Other
events (single-step, method entry/exit, ...) are handled differently
and LocationOnly modifier is used as an event filter in this case.
This prevents from failing a check when we need to deoptimize for
non-breakpoint event.
Bug: 17908144
Change-Id: Ib413d62fa31480fec8d750543c0605ba52188350
|
| a9aa0ffc2cf917be05749d1b27e7994249edb6d2 |
|
19-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP crash when reporting exception
The exception's throw location may be null so we need to handle that
case. Also fixes a memset issue.
Bug: 17571297
(cherry picked from commit bbb63897d7f2d99219cb50721fe530521e08ddff)
Change-Id: Iedebb58f9460c5f04913c269200e51161bda1ba9
|
| bbb63897d7f2d99219cb50721fe530521e08ddff |
|
19-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP crash when reporting exception
The exception's throw location may be null so we need to handle that
case. Also fixes a memset issue.
Bug: 17571297
Change-Id: I954b67207b1ba99a8f3240ce936579dc5644cc69
|
| dcfd6cad9670ca3ae460a4af0bbe7d88cae21a3c |
|
18-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Move spammy logs to JDWP verbose mode
We are spammed by warning messages when debugging, especially each time we
suspend/resume all threads (to update instrumentation or collect monitor info).
It's common to get into the cases where these warnings are logged so they
shouldn't be warning but debug messages.
This CL moves these LOG(WARNING) to VLOG(jdwp) to not disturb developers when
debugging their app (especially when looking for specific messages in logcat).
We keep them in JDWP verbose mode because they help knowing when we initiate
these sequences of "suspend/resume all threads".
Also adds debug suspend count in the log message for more context.
Bug: 17524544
Bug: 17170697
(cherry picked from commit f272af4b9dcd39cdd50fa6655601a26e837eaea9)
Change-Id: I61df70ace1475bf10d83202b6bb774f7036354cb
|
| 6995c60cd6657c10811055c42661a55b10b47cef |
|
09-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Update JDWP event filtering to avoid useless ids
To reduce the number of JDWP ids in the debugger, we update the event filtering
support to work with runtime objects (Thread, Class, Object, ...) instead of
JDWP ids (ThreadId, RefTypeId, ObjectId, ...).
We used to create useless JDWP ids for events even if they were not reported
because of event filtering (thread only, class only, instance only, ...). Now
we only create JDWP ids when we know we're going to report an event.
Bug: 17343664
(cherry picked from commit d539167b7f11136fe570a77aff2ee4935842007a)
Change-Id: I8619e219733fc2fa3569f473b7bd8d9af4181f2b
|
| f272af4b9dcd39cdd50fa6655601a26e837eaea9 |
|
18-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Move spammy logs to JDWP verbose mode
We are spammed by warning messages when debugging, especially each time we
suspend/resume all threads (to update instrumentation or collect monitor info).
It's common to get into the cases where these warnings are logged so they
shouldn't be warning but debug messages.
This CL moves these LOG(WARNING) to VLOG(jdwp) to not disturb developers when
debugging their app (especially when looking for specific messages in logcat).
We keep them in JDWP verbose mode because they help knowing when we initiate
these sequences of "suspend/resume all threads".
Also adds debug suspend count in the log message for more context.
Bug: 17524544
Bug: 17170697
Change-Id: Ic87985ac6913151d15fd89849e41bde61092c3dd
|
| d539167b7f11136fe570a77aff2ee4935842007a |
|
09-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Update JDWP event filtering to avoid useless ids
To reduce the number of JDWP ids in the debugger, we update the event filtering
support to work with runtime objects (Thread, Class, Object, ...) instead of
JDWP ids (ThreadId, RefTypeId, ObjectId, ...).
We used to create useless JDWP ids for events even if they were not reported
because of event filtering (thread only, class only, instance only, ...). Now
we only create JDWP ids when we know we're going to report an event.
Bug: 17343664
Change-Id: Ib83df6d82fbcb40895f5cd9201a1e9ecd0a07e17
|
| c0542af3e2170143ba40d89136e284997e16bf64 |
|
04-Sep-2014 |
Ian Rogers <irogers@google.com> |
Remove abuse of mirror::Object* to reference special values.
Remove kInvalidIndirectRefObject, kClearedJniWeakGlobal and
ObjectRegistry::kInvalidObject. Handle error conditions by passing in or
returning an error value.
GetObjectRefType is simplified to be faster and not return invalid references
that are not expected according to the spec. Adjust check JNI and
jni_internal_test appropriately.
Fix cases in the debugger/JDWP of out arguments being passed by reference.
Bug: 17376993
Change-Id: I3ce8a28c01827e163f4dc288449959464da788b1
|
| 0ec17d2ddb69d3f5c46ccad62e82c0ffd6219428 |
|
07-Jul-2014 |
Hiroshi Yamauchi <yamauchi@google.com> |
Remove Dbg::VisitRoots().
We replace the GC strong roots with JNI.
jdwp_test passes.
Bug: 12687968
Change-Id: I841f1aaa5dffa784ca25953a251600f70df273b2
|
| bca0d3d0279e9a75b4aec827b40cdb267e1e990e |
|
11-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
More verbose logs for JDWP events
Logs more information about the JDWP event being reported with VLOG(jdwp). This
helps mainly when debugging JDWP with -verbose:jdwp option.
Change-Id: I49495bdab03dbcbdc0b6c00a8df718bfedbad91d
|
| 42cd43fa593e8f0427eb0ec158bef08814a6180b |
|
13-May-2014 |
Sebastien Hertz <shertz@google.com> |
Register debugger for interesting instrumentation events only
This avoids the overhead of notifying events (like method entry/exit, field
read/write, ...) from the interpreter when they are not requested on the JDWP
side. It also avoids burning JDWP ids for objects and classes before we find
out we do not need to report the event.
When we register a JDWP event (like a breakpoint), we add the debugger as
a listener for the corresponding instrumentation event (like kDexPcChanged).
On the other hand, when a JDWP event is cleared, we remove the debugger as a
listener for the corresponding instrumentation event. To control we add/remove
the debugger as listener only once per instrumentation event, we use reference
counting.
Like deoptimization, we can update instrumentation listeners only when when all
mutator threads are suspended. To add or remove the debugger as listener, we
extend the support of deoptimization requests to a more general support dealing
with instrumentation requests.
We add kRegisterForEvent and kUnregisterForEvent request kinds, respectively to
add or remove the debugger as a listener for a given instrumentation event.
Note: we will rename the related classes, methods, ... to avoid pollution in
the code review.
This CL also fixes Instrumentation::IsActive to take field read/write events
into account.
Bug: 14401699
Bug: 14826953
Change-Id: Ic896469e82a8589de419ebea4b9dc3116925f3ab
|
| 4d466a8e4587422c989705dce3b2a19e7f0137f5 |
|
09-May-2014 |
Brian Carlstrom <bdc@google.com> |
Remove all LOG(DEBUG) which is not intended to be checked in
Bug: 14632493
Change-Id: Id9da8b87798af0a1b2bd2c178133e5f1ba47d43d
|
| 479fc1ecc12fa6560ca90d841c4d5174fb346618 |
|
04-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Support field watchpoint in interpreter
We report field read/write events to instrumentation from the interpreter. This
allows it to send JDWP field access and field modification events to debugger.
This completes CL https://android-review.googlesource.com/90390.
We also fix the JDWP FieldOnly modifier by introducing ModBasket.fieldTypeID.
We incorrectly used ModBasket.classId which is actually dedicated to ClassOnly
modifier based on thread's location's class id.
Finally, we now enable canWatchFieldModification and canWatchFieldAccess JDWP
capabilities so a debugger can request these events to be reported.
Bug: 8267708
Change-Id: I987852ad47abb27b2f7e78544a8189c7a4e2f462
|
| 43207797d05e54fb945e2fc22145722cb26cb27b |
|
15-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP count event modifier
Bug: 14053614
Change-Id: I736f6d6802e58e7a4fb29d0558bdd2abd3b2a48e
|
| 3f52eafe5577b8489f90dc8ed5981b3455206147 |
|
04-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Prepare field watchpoint support
Adds field read/write events in the instrumentation. The debugger now registers
as a listener for these events so JDWP field access and field modification
events can be reported.
This CL will be followed by another one to report these events from the
interpreter. Therefore no JDWP field access and field modification events
can be sent for now.
Bug: 8267708
Change-Id: If2a93eb590805567d69015c83cce9cd2ab712cbd
|
| 7ec2f1ca3cbd021848da75d5566f7239ce29676f |
|
27-Mar-2014 |
Sebastien Hertz <shertz@google.com> |
Speed up single-stepping
During single-stepping sequence, we need to deoptimize everything when we
register a single-step event and undeoptimize everything when it is done. This
causes a slow pattern where we continuously deoptimize-undeoptimize everything
for each single-step.
This CL introduces a special handling of single-step undeoptimization. We now
delay the undeoptimization to the next resume (one thread or all threads) or
the end of the debugging session. Indeed, a single-step event registration is
always followed by a resume command.
At the "resume" point, we know if a single-step event is registered and if we
really need to undeoptimize. At the "registration" point, we know we did not
undeoptimized everything so we don't need to deoptimize everything again.
Therefore, in a sequence of single-steps, we only do a full deoptimization for
the first single-step and a full undeoptimization for the last single-step.
We update logs at deoptimization points so we can track more precisely. Note
they are verbose logs that still must be enabled with -verbose:jdwp option.
We also make some improvement inside instrumentation:
* updates Instrumentation::ShouldNotifyMethodEnterExitEvents to comply with its
name.
* compute frame id only once when looking for the corresponding instrumentation
frame.
* compute the OatMethod once in ClassLinker::GetPortableOatCodeFor to avoid
looking for it again.
Bug: 13577964
Change-Id: If6fa198a676b515cd474b8c4d7bf7ef3626f2dc7
|
| 4d25df3f76f864b7629ac8c0046d46997f293d8d |
|
21-Mar-2014 |
Sebastien Hertz <shertz@google.com> |
Refactor deoptimization support in debugger
This CL prepares breakpoint support for inlined methods where we'll have to
deoptimize everything.
We move deoptimization-related information to Dbg class only (deoptimization
request queue, full deoptimization event count and deoptimization lock). We
replace MethodInstrumentionRequest by DeoptimizationRequest. This is used to
know which kind of deoptimization is required for a particular event.
It also simplifies lock ordering a bit during event setup: we no longer need to
hold the deoptimization lock while holding the breakpoint lock. Moreover, the
deoptimization lock should be held only after the event list lock.
Bug: 12187616
Change-Id: Iff13f004adaeb25e5d609238bacce0b9720510e6
|
| 99660e1c3d6117cfb8bac25b1a0413833ab15b2a |
|
19-Feb-2014 |
Sebastien Hertz <shertz@google.com> |
Avoid interleaving JDWP requests and events.
To avoid bad synchronization between the debugger and the debuggee, we should
not send any events while processing a request (before sending its reply).
This particularly prevents from sending the VM_DEATH event (and consequently
closing the JDWP connection) after receiving the VM_Resume command but before
sending its reply.
Bug: 12581527
Change-Id: I197cc54e980a983faae4b545f25dfe7fe812e841
|
| 21e729c7859ce7909e85d135f6c9e32bbba38860 |
|
18-Feb-2014 |
Sebastien Hertz <shertz@google.com> |
Fix failing check during JDWP invoke.
Fixes a race where the JDWP thread expects the invoke thread can be suspended
(suspend_count != 0) before invoke thread actually updates its suspend count.
It happens after the invoke thread signals the JDWP thread to notify invoke is
completed but before incrementing its suspend count. In the meantime, the JDWP
thread wakes up and checks whether invoke thread has updated its supend count.
But there is no way to prevent the JDWP thread to do so before the invoke
thread updates its suspend count.
We now move the invoke completion code after the suspend count update. Then the
JDWP thread wakes up at the right time.
Bug: 11247837
Bug: 12578041
Change-Id: Ib6079c6e330671b34217838e26b1e758706d3da6
|
| d9e4e0c8606f8b87e0a48aab68125dbee543bf88 |
|
24-Jan-2014 |
Ian Rogers <irogers@google.com> |
64bit friendly printf modifiers in JDWP.
Change-Id: I105da6393b31f5901036216fbfe19a71c46cf152
|
| 138dbfc3336e379d74d157086f69a0fbe830089b |
|
04-Dec-2013 |
Sebastien Hertz <shertz@google.com> |
Selective deoptimization.
Update the instrumentation to allow selective deoptimization.
Separate instrumentation listener registration from stubs configuration. A
listener is now responsible for configuring the appropriate stubs.
- The method tracing listener installs instrumentation entry/exit stubs or
the interpreter depending on the accuracy of events we want (controlled by
kDeoptimizeForAccurateMethodEntryExitListeners).
- The debugger registers itself as an instrumentation listener but does not
modify methods entrypoints. It only does this on demand when deoptimizing one
method or all the methods.
The selective deoptimization is used for breakpoint only. When a breakpoint is
requested, the debugger deoptimizes this method by setting its entrypoint to
the interpreter stub. As several breakpoints can be set on the same method, we
deoptimize only once. When the last breakpoint on a method is removed, we
reoptimize it by restoring the original entrypoints.
The full deoptimization is used for method entry, method exit and single-step
events. When one of these events is requested, we force eveything to run with
the interpreter (except native and proxy methods). When the last of these
events is removed, we restore all methods entrypoints except those which are
currently deoptimized.
Deoptimizing a method requires all mutator threads be suspended in order to
walk each thread's stack and ensure no code is actually executing while we
modify methods entrypoints. Suspending all the threads requires to not hold
any lock.
In the debugger, we deoptimize/undeoptimize when the JDWP event list changes
(add or remove a breakpoint for instance). During the update, we need to hold
the JDWP event list lock. This means we cannot suspend all the threads at this
time.
In order to deal with these constraints, we support a queue of deoptimization
requests. When an event needs selective/full deoptimization/undeoptimization,
we save its request in the queue. Once we release the JDWP event list lock, we
suspend all the threads, process this queue and finally resume all the threads.
This is done in Dbg::ManageDeoptimization. Note: threads already suspended
before doing this remain suspended so we don't "break" debugger suspensions.
When we deoptimize one method or every method, we need to browse each thread's
stack to install instrumentation exit PC as return PC and save information in
the instrumentation stack frame. Now we can deoptimize multiple times during
the execution of an application, we need to preserve exisiting instrumentation
frames (which is the result of a previous deoptimization). This require to push
new instrumentation frames before existing ones so we don't corrupt the
instrumentation stack frame while walking the stack.
Bug: 11538162
Change-Id: I477142df17edf2dab8ac5d879daacc5c08a67c39
|
| d38667a055d507492fd05f78519a7e1f0b85ea03 |
|
25-Nov-2013 |
Sebastien Hertz <shertz@google.com> |
Minor field name cleanup in debugger.
Use the same naming convention for all fields of DebugInvokeReq structure.
Change-Id: Ieaf65eef592f96efa47975eef15334279ed4fc8a
|
| 579b02416e05e32e535126e1ed61613a2cdb030e |
|
18-Nov-2013 |
Jeff Hao <jeffhao@google.com> |
Add support for JDWP METHOD_EXIT_WITH_RETURN_VALUE events.
Bug: 11569539
Change-Id: Ibc7a80df83470ffd726d73695a05f4938248f292
|
| 7934ac288acfb2552bb0b06ec1f61e5820d924a4 |
|
26-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fix cpplint whitespace/comments issues
Change-Id: Iae286862c85fb8fd8901eae1204cd6d271d69496
|
| f52935278fca8c7aa220543eef4544e3d1105d91 |
|
19-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Move JDWP to std::vector<iovec> to remove runtime/arrays warning
Change-Id: I8494a25a65de4ebac2b1f4f41c0f5eedf117b7ac
|
| fb6996fe2b1bb28526751650441d7ac29dcdb4e6 |
|
19-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fixing cpplint runtime/arrays, runtime/int, runtime/virtual issues
Change-Id: Ia2ff94d2fb69465df26aaf83df82614a483b26e0
|
| 38f85e4892f6504971bde994fec81fd61780ac30 |
|
18-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fix cpplint whitespace/operators issues
Change-Id: I730bd87b476bfa36e93b42e816ef358006b69ba5
|
| 7940e44f4517de5e2634a7e07d58d0fb26160513 |
|
12-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Create separate Android.mk for main build targets
The runtime, compiler, dex2oat, and oatdump now are in seperate trees
to prevent dependency creep. They can now be individually built
without rebuilding the rest of the art projects. dalvikvm and jdwpspy
were already this way. Builds in the art directory should behave as
before, building everything including tests.
Change-Id: Ic6b1151e5ed0f823c3dd301afd2b13eb2d8feb81
|