| 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
|
| 738c4c909c7668bc80b0d12f9b818061115e5c6f |
|
02-Sep-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: attempt to fix failure on closed connection
Don't send packet if JDWP connection has been closed while
processing a JDWP command.
We used to DCHECK(IsConnected()) in JdwpNetStateBase::WritePacket
but this is wrong when the connection has been closed by the debugger
(client) before we sent the packet. It seems to happen more during
JDWP tests due to how debugger and debuggee are synchronizing with
each other.
Bug: 22907762
Change-Id: I1c886382268697b4c50755b6009cceac7b8d656e
|
| c60e1b755c5632dfeb04c333489ede52ee5c945f |
|
30-Jul-2015 |
Andreas Gampe <agampe@google.com> |
ART: Use __ANDROID__ instead of HAVE_ANDROID_OS
Use the proper define.
Change-Id: I71e291ac25f5d5f0187ac9b6ef2d6872f19e6085
|
| 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
|
| 41b175aba41c9365a1c53b8a1afbd17129c87c14 |
|
19-May-2015 |
Vladimir Marko <vmarko@google.com> |
ART: Clean up arm64 kNumberOfXRegisters usage.
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
|
| 80afd02024d20e60b197d3adfbb43cc303cf29e0 |
|
19-May-2015 |
Vladimir Marko <vmarko@google.com> |
ART: Clean up arm64 kNumberOfXRegisters usage.
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
Change-Id: I704884dab15b41ecf7a1c47d397ab1c3fc7ee0f7
|
| 4e5b20863898006ec6c9d120cda167d38dda6e60 |
|
24-Mar-2015 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP race at runtime shutdown
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
|
| 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>
|
| 184c9dc3bfc500134fdb2fbea0a7fab290c0abb0 |
|
05-Mar-2015 |
Mathieu Chartier <mathieuc@google.com> |
Fix some incorrect IsCompiler instead of IsAotCompiler
Fixes jdwp related issues (DDMS) when JIT is enabled.
Bug: 19623297
Change-Id: I36139c70a97b529135febcf01b227e7ab9affacc
|
| 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
|
| aaebaa0121be3b9d9f13630585304482cbcaeb4b |
|
26-Jan-2015 |
Igor Murashkin <iam@google.com> |
art: Refactor RuntimeOptions/ParsedOptions
Refactor the RuntimeOptions to be a
type-safe map (VariantMap, see runtime_options.h) and the ParsedOptions
to delegate the parsing to CmdlineParser (see cmdline/cmdline_parser.h).
This is the start of a command line parsing refactor, and may include
more in the future (dex2oat, patchoat, etc).
For more details of the command line parsing generator usage see cmdline/README.md
Change-Id: Ic67c6bca5e1f33bf2ec60e2e3ff8c366bab91563
|
| 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
|
| 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
|
| 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
|
| 8ac3356db74f5e38c70406cc5f5e65a49ff41fd7 |
|
28-Aug-2014 |
Sebastien Hertz <shertz@google.com> |
Avoid null pointer dereference when sending JDWP packets
Bug: 16218394
(cherry picked from commit 60ed7da4d193e0f90b05c4236af77d3b276c0ea4)
Change-Id: I4882b3b6bb97facb8fca4c7ece65f4c7c96c57fe
|
| 60ed7da4d193e0f90b05c4236af77d3b276c0ea4 |
|
28-Aug-2014 |
Sebastien Hertz <shertz@google.com> |
Avoid null pointer dereference when sending JDWP packets
Bug: 16218394
Change-Id: Id0ab09401b01f3041ea36013330a000d7702d8fa
|
| c6345efb56f9096c4b1a1a90e1d8d847fc01d910 |
|
18-Aug-2014 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP event races
Fix a race where the JDWP connection could be closed before the VM_DEATH event
is sent during runtime shutdown.
Fix potential race where we could wait forever for the JDWP thread to establish
connection.
Bug: 16720689
(cherry picked from commit d8b3537b89fa68599534a65afc3b272639cd4a75)
Change-Id: I4b8996ade6a38fa8f7f23c3000b7184b162907d7
|
| d8b3537b89fa68599534a65afc3b272639cd4a75 |
|
18-Aug-2014 |
Sebastien Hertz <shertz@google.com> |
Fix JDWP event races
Fix a race where the JDWP connection could be closed before the VM_DEATH event
is sent during runtime shutdown.
Fix potential race where we could wait forever for the JDWP thread to establish
connection.
Bug: 16720689
Change-Id: I227e0a15a2fd17d7bfe2a66a35d719d558fcd32d
|
| 37f3c968ecd04e77802fe17bb82dabc07de21ca1 |
|
17-Jul-2014 |
Ian Rogers <irogers@google.com> |
Avoid direct use of QuasiAtomic by using Atomic.
Change-Id: I92d0f822cddb2085de7cbb4c44c3a429081892a2
|
| 700a402244a1a423da4f3ba8032459f4b65fa18f |
|
20-May-2014 |
Ian Rogers <irogers@google.com> |
Now we have a proper C++ library, use std::unique_ptr.
Also remove the Android.libcxx.mk and other bits of stlport compatibility
mechanics.
Change-Id: Icdf7188ba3c79cdf5617672c1cfd0a68ae596a61
|
| 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
|
| bb5c355df9d93d103f1a008fba485d03c56465b5 |
|
14-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Deduplicate code starting JDWP thread
Also waits for thread_start_cond_ in a loop and removes needless mutex lock in
JdwpState::Run when checking thread state.
Change-Id: I6fca2151b5343b2906e9fa3b439029e6ad5b086d
|
| 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
|
| 43c8d729556844d1a74449a8a300c795d6a5406a |
|
18-Mar-2014 |
Sebastien Hertz <shertz@google.com> |
Do not send JDWP data in case of error.
When sending JDWP reply packet with an error, we want to ignore any data in the
buffer. While we reflect that in the packet's length (first 4 bytes), we used
to send all data in the buffer. This causes the receiver to read malformed JDWP
packet.
This CL adds "length" argument to JdwpNetStateBase::WritePacket so we control
the amount of data we send. If the reply has no error, it is set to the length
of the buffer. Otherwise it is the length of JDWP packet header indicating no
data is available.
Bug: 13366758
Change-Id: Ib72c10d5faf065fb44901c34b2732496b6667efa
|
| 400a3a9d332ee17e69b876cbbfb47d9e576fc4f2 |
|
24-Feb-2014 |
Sebastien Hertz <shertz@google.com> |
Fix debugger deadlock.
Fixes a deadlock between the event thread lock and the processing request
lock where the JDWP thread and the event thread wait for each other. We now
move the call to StartProcessingRequest after the call to SetWaitForEventThread
in JdwpState::ProcessRequest so locks are taken in the same order in both
threads.
Also adds some thread safety annotations and JDWP verbose logs for debug (only
enabled if we pass the -verbose:jdwp option to the runtime).
Bug: 13165103
Change-Id: I4e8b6526d973bfee56e69e8e14eddf56adfa1939
|
| 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
|
| 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
|
| f52935278fca8c7aa220543eef4544e3d1105d91 |
|
19-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Move JDWP to std::vector<iovec> to remove runtime/arrays warning
Change-Id: I8494a25a65de4ebac2b1f4f41c0f5eedf117b7ac
|
| 4b95e8fad803ad307fa09c11c08894544e07a731 |
|
16-Jul-2013 |
Mathieu Chartier <mathieuc@google.com> |
Refactor atomic integer.
Refactored atomic integer to be similar to c++11 std::atomic<int>.
Removed jdwp serial lock and reverted lock level name change from
https://googleplex-android-review.googlesource.com/#/c/327297/
Change-Id: I2229f30c4d5762a0e8c72697d6aca4683750af35
|
| add037df2399821eb048a5d9146a9d2174bcd1bd |
|
15-Jul-2013 |
Jeff Hao <jeffhao@google.com> |
Fix jdwp to not hold start lock while waiting on attach lock.
Change-Id: Ic2600ea162802bfcbb7f20f356fd5c46894a98c5
|
| 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
|