| 70fa1a5497c057eecf336c60975fbca015f8aebd |
|
25-Feb-2016 |
Alex Light <allight@google.com> |
Support new JDWP InterfaceType.InvokeMethod command
This command is used to invoke static methods in interfaces.
(cherry picked from commit 4a28e1e4e02aa44aa6fd20e22d50f9d73f6279cc)
Bug: 27218415
Change-Id: Ie4dc1876a20567240267f309dc18f1aec2c1b4c2
|
| 4a28e1e4e02aa44aa6fd20e22d50f9d73f6279cc |
|
25-Feb-2016 |
Alex Light <allight@google.com> |
Support new JDWP InterfaceType.InvokeMethod command
This command is used to invoke static methods in interfaces.
Bug: 27218415
Change-Id: Ie4dc1876a20567240267f309dc18f1aec2c1b4c2
|
| 0a97fc6613d525370d9300819a3579f706d6fc67 |
|
09-Nov-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: default implementation of Method.IsObsolete
To please some IDEs sending this command, adds a default
implementation that a method is never obsolete.
Bug: 25552174
Bug: https://code.google.com/p/android/issues/detail?id=192784
Change-Id: I328522e6313f2ef5474897cad15a95edd33cd15c
|
| 358bcaf13ec288ee45be8fc53cb09170c1b8a8f1 |
|
21-Oct-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: fix possible JdwpEvent memory leak
Fixes possible memory leak when registering new JdwpEvent but the
Count modifier is invalid. This is done by using a std::unique_ptr
with a custom delete function. It also allows to easily introduce
more modifier checks in the future.
Bug: 14076832
Change-Id: I339ffb1297165ff85ab924e5e7618d336df5612b
|
| 4b8f1ecd3aa5a29ec1463ff88fee9db365f257dc |
|
26-Aug-2015 |
Roland Levillain <rpl@google.com> |
Use ATTRIBUTE_UNUSED more.
Use it in lieu of UNUSED(), which had some incorrect uses.
Change-Id: If247dce58b72056f6eea84968e7196f0b5bef4da
|
| 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
|
| 3901bbc170b73b13aa5092f5709a495a1847198f |
|
06-Aug-2015 |
Sebastien Hertz <shertz@google.com> |
Fix DDM reply buffer deallocation
Reply buffer is an uint8_t* allocated with new uint8_t[...] so it
must be deallocated with delete[], not free.
Change-Id: Ib5d6387aa63f1e0393113f82602f661bbada4aa2
|
| 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
|
| 2cebb24bfc3247d3e9be138a3350106737455918 |
|
22-Apr-2015 |
Mathieu Chartier <mathieuc@google.com> |
Replace NULL with nullptr
Also fixed some lines that were too long, and a few other minor
details.
Change-Id: I6efba5fb6e03eb5d0a300fddb2a75bf8e2f175cb
|
| 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
|
| 2c3e77a0b91b2225fcdd3b34d8a734b85eec0579 |
|
02-Apr-2015 |
Sebastien Hertz <shertz@google.com> |
JDWP: clear exception when allocation fails
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
|
| 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>
|
| 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
|
| 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
|
| e6c143fae8ec487704b3d0d28914cda3d6d19e88 |
|
13-Jan-2015 |
Sebastien Hertz <shertz@google.com> |
Fix bootclasspath string initialization
When running the runtime with an image without explicitly specifying
the bootclasspath (with the -Xbootclasspath option), we construct it
from the location of DEX files loaded from the image.
This allows to fix the JDWP test ClassPathsTest#testClassPaths001 on
the host where the bootclasspath is not explicitly specified on the
command line.
Bug: 18812378
Change-Id: I726eafd8b9e59dc9513beeb7082cf086fe89c4b1
|
| 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
|
| 6d7839e03348111a4237f0d47d0e70bc81b32e7a |
|
05-Dec-2014 |
Sebastien Hertz <shertz@google.com> |
JDWP: avoid crash on unsupported modifier
Returns NOT_IMPLEMENTED error if we receive an event request with an
unsupported modifier.
Bug: https://code.google.com/p/android/issues/detail?id=81037
Bug: 18617787
(cherry picked from commit 0fb33e7b7b0b86fb9c7b556e4a052874ec269bb0)
Change-Id: I97729e2f98af3a75d24604926a89860255d4acae
|
| 0fb33e7b7b0b86fb9c7b556e4a052874ec269bb0 |
|
05-Dec-2014 |
Sebastien Hertz <shertz@google.com> |
JDWP: avoid crash on unsupported modifier
Returns NOT_IMPLEMENTED error if we receive an event request with an
unsupported modifier.
Bug: https://code.google.com/p/android/issues/detail?id=81037
Bug: 18617787
Change-Id: I97729e2f98af3a75d24604926a89860255d4acae
|
| 6a3c1fcb4ba42ad4d5d142c17a3712a6ddd3866f |
|
31-Oct-2014 |
Ian Rogers <irogers@google.com> |
Remove -Wno-unused-parameter and -Wno-sign-promo from base cflags.
Fix associated errors about unused paramenters and implict sign conversions.
For sign conversion this was largely in the area of enums, so add ostream
operators for the effected enums and fix tools/generate-operator-out.py.
Tidy arena allocation code and arena allocated data types, rather than fixing
new and delete operators.
Remove dead code.
Change-Id: I5b433e722d2f75baacfacae4d32aef4a828bfe1b
|
| 677cd61ad05d993c4d3b22656675874f06d6aabc |
|
15-Oct-2014 |
Ian Rogers <irogers@google.com> |
Make ART compile with GCC -O0 again.
Tidy up InstructionSetFeatures so that it has a type hierarchy dependent on
architecture.
Add to instruction_set_test to warn when InstructionSetFeatures don't agree
with ones from system properties, AT_HWCAP and /proc/cpuinfo.
Clean-up class linker entry point logic to not return entry points but to
test whether the passed code is the particular entrypoint. This works around
image trampolines that replicate entrypoints.
Bug: 17993736
(cherry picked from commit 6f3dbbadf4ce66982eb3d400e0a74cb73eb034f3)
Change-Id: I3e7595f437db4828072589d475a5453b7f31003e
|
| 6f3dbbadf4ce66982eb3d400e0a74cb73eb034f3 |
|
15-Oct-2014 |
Ian Rogers <irogers@google.com> |
Make ART compile with GCC -O0 again.
Tidy up InstructionSetFeatures so that it has a type hierarchy dependent on
architecture.
Add to instruction_set_test to warn when InstructionSetFeatures don't agree
with ones from system properties, AT_HWCAP and /proc/cpuinfo.
Clean-up class linker entry point logic to not return entry points but to
test whether the passed code is the particular entrypoint. This works around
image trampolines that replicate entrypoints.
Bug: 17993736
Change-Id: I5f4b49e88c3b02a79f9bee04f83395146ed7be23
|
| 5d1c1bbd4c8a1727027d0ae69277af6f6f6badf3 |
|
15-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Check for errors in ThreadGroupReference JDWP commands
Returns INVALID_OBJECT error for null or invalid object. Also returns
INVALID_THREAD_GROUP error when the object is not a java.lang.ThreadGroup.
Removes unused Dbg::GetMainThreadGroupId method.
Bug: 17503230
(cherry picked from commit a06430c76981d545b5f2b64a7ef53c44c030cf73)
Change-Id: Ic39d3d2c45bf288fc22d908a3c90a3ca24f1c4d4
|
| 5797aef3bbfa6fc762d384e25b31f6a121664987 |
|
01-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Optimize JDWP stack local values access
The StackFrame.GetValues and StackFrame.SetValues JDWP commands can refer to
multiple variables at the same time in a given frame. However we used to walk
the stack until getting to the requested frame for each variable.
Now, we walk the stack only once until getting to the frame so the context is
initialized. Then we read/write value for each variable from this context.
Bug: 17343501
Bug: 15680615
(cherry picked from commit 8009f39c6d63181a6cd0e348ce732997dbdf3d20)
Change-Id: I70f64b25e4b20860f5446b8c540345d5e71ec4a9
|
| 8009f39c6d63181a6cd0e348ce732997dbdf3d20 |
|
01-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Optimize JDWP stack local values access
The StackFrame.GetValues and StackFrame.SetValues JDWP commands can refer to
multiple variables at the same time in a given frame. However we used to walk
the stack until getting to the requested frame for each variable.
Now, we walk the stack only once until getting to the frame so the context is
initialized. Then we read/write value for each variable from this context.
Bug: 17343501
Bug: 15680615
Change-Id: I2a4128f29a3c5856b994e280037c0a09eb48c5c8
|
| b0b0b496125c16620e99ea4e4a05693c281eccf1 |
|
15-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Avoid crash in StringReference.Value JDWP command
Checks for null or invalid object id. Also checks whether the corresponding
object is a java.lang.String.
Bug: 17492221
Bug: 15005460
(cherry picked from commit 29259fa6b0514866d2d4bf57d58c1557b26abbb7)
Change-Id: I52673bdef6912a4cccf5a6eeecb6e1e817b9dd6b
|
| a06430c76981d545b5f2b64a7ef53c44c030cf73 |
|
15-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Check for errors in ThreadGroupReference JDWP commands
Returns INVALID_OBJECT error for null or invalid object. Also returns
INVALID_THREAD_GROUP error when the object is not a java.lang.ThreadGroup.
Removes unused Dbg::GetMainThreadGroupId method.
Bug: 17503230
Change-Id: Ifae39b0280633836655b22fc212018cb06b65c6c
|
| 29259fa6b0514866d2d4bf57d58c1557b26abbb7 |
|
15-Sep-2014 |
Sebastien Hertz <shertz@google.com> |
Avoid crash in StringReference.Value JDWP command
Checks for null or invalid object id. Also checks whether the corresponding
object is a java.lang.String.
Bug: 17492221
Bug: 15005460
Change-Id: I2e9afe2ade69b130e59a5a0c00d02ded20b05b94
|
| 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
|
| cc2f2393e69a9b1425bad1a89f41aaaf8c38f9e2 |
|
30-Aug-2014 |
Ian Rogers <irogers@google.com> |
Reduce and speed-up class def searches.
Use the class linker for descriptor lookups from the compile driver so that
dex caches are populated.
Reduce the scope of functions for scanning class paths to just the class
linker where they are performed.
If we see more than a threshold number of find class def misses on a dex file
lazily compute an index, so that future lookups are constant time (part of the
collection code is taken from
https://android-review.googlesource.com/#/c/103865/3). Note that we take a lazy
approach so that we don't serialize on loading dex files, this avoids the
reason the index was removed in 8b2c0b9abc3f520495f4387ea040132ba85cae69.
Remove an implicit and unnecessary std::string creation for PrintableString.
Single threaded interpret-only dex2oat performance is improved by roughly 10%.
Bug: 16853450
Change-Id: Icf72df76b0a4328f2a24075e81f4ff267b9401f4
(cherry picked from commit 68b56858367e29461ae290fd797443a1ef6d8005)
|
| 68b56858367e29461ae290fd797443a1ef6d8005 |
|
30-Aug-2014 |
Ian Rogers <irogers@google.com> |
Reduce and speed-up class def searches.
Use the class linker for descriptor lookups from the compile driver so that
dex caches are populated.
Reduce the scope of functions for scanning class paths to just the class
linker where they are performed.
If we see more than a threshold number of find class def misses on a dex file
lazily compute an index, so that future lookups are constant time (part of the
collection code is taken from
https://android-review.googlesource.com/#/c/103865/3). Note that we take a lazy
approach so that we don't serialize on loading dex files, this avoids the
reason the index was removed in 8b2c0b9abc3f520495f4387ea040132ba85cae69.
Remove an implicit and unnecessary std::string creation for PrintableString.
Single threaded interpret-only dex2oat performance is improved by roughly 10%.
Bug: 16853450
Change-Id: Icf72df76b0a4328f2a24075e81f4ff267b9401f4
|
| 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
|
| 507dfdd147c97bfbadebfd63584d094b6a4e7b47 |
|
16-May-2014 |
Ian Rogers <irogers@google.com> |
Compatibility layer to transition from UniquePtr to std::unique_ptr.
Use ART_WITH_STLPORT (enabled for the target) to cause the use of UniquePtr,
for the host switch to std::unique_ptr. For now the type remains called
UniquePtr.
Make dalvik compile with clang on the host, move its build to C++11.
Change-Id: I5ba8d2757904bc089ed62047ea03de3c0853fb12
|
| 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
|
| cf7bea35a401af5914efeafd8d488866f36faf1a |
|
16-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Disable JDWP field watchpoint capabilities
We do not fully support field watchpoint yet. We can only enable these
capabilities when we do report these events.
Bug: 8267708
Change-Id: I07ccf7ddffdd26e143b7fb0f13ebe030d75e8491
|
| 5f4e6f56fcc4289eed73e7ad00d874148aeb68d1 |
|
11-Apr-2014 |
Sebastien Hertz <shertz@google.com> |
Allow use of instance filter for JDWP events
Bug: 13922844
Change-Id: Ic4e6d7af7c80928c25417db5f43049614d225c97
|
| 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
|
| 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
|
| cb19ebf7609f74b223bd86c94f721498795f9bba |
|
11-Mar-2014 |
Sebastien Hertz <shertz@google.com> |
Fix debugger crash in native method frames.
The main crash happens when we try to read (StackFrame::GetValues) or write
(StackFrame::SetValues) values in native frames. We use the method's vmap to
know where Dalvik registers live but native methods don't have vmap. The fix
is to reply with the OPAQUE_FRAME error which indicates local values are not
accessible in the frame.
We prevent from dereferencing null code item which causes some crashes too.
This happens when we compute the line table (Method::LineTable) and variable
table (Method::VariableTable) of methods without code: native, proxy and
abstract methods. We do not expect to encounter abstract methods though. We
take care of these kinds of method when mangling/demangling local value slots.
We also fix the location's pc of native and proxy frames where it must be -1
(as 8-byte value). We'll use this property to detect such frames in the JDWP
tests.
Bug: 13366758
Change-Id: I78e3263fbf2681b5573571c846390d52b9193849
|
| 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
|
| 43b2e0f9105848da6470458e7c04bf1fd7fcb25c |
|
31-Jan-2014 |
Ian Rogers <irogers@google.com> |
Fix multi-line hex dumping and add unit test.
Change-Id: I7657018fef5d9c17410a9a634db275555f180014
|
| d9e4e0c8606f8b87e0a48aab68125dbee543bf88 |
|
24-Jan-2014 |
Ian Rogers <irogers@google.com> |
64bit friendly printf modifiers in JDWP.
Change-Id: I105da6393b31f5901036216fbfe19a71c46cf152
|
| fc0e94bed3f88ed7e50854fd8dfaf5dcb345250f |
|
24-Sep-2013 |
Ian Rogers <irogers@google.com> |
StringPiece clean up.
Profile guided clean up.
Try to avoid creating StringPieces with the contents of a dex file where
the length is known.
Try to avoid RegTypeCache::FromDescriptor when there's a class available.
Make ConstantType::ConstantValue inlinable.
Saving of about 50ms from a 2 threaded ThinkFree compile on host.
Change-Id: I47a12c3c76f46e2c9805be1c3a3e3870fe1f5d85
|
| 7934ac288acfb2552bb0b06ec1f61e5820d924a4 |
|
26-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fix cpplint whitespace/comments issues
Change-Id: Iae286862c85fb8fd8901eae1204cd6d271d69496
|
| 0cd7ec2dcd8d7ba30bf3ca420b40dac52849876c |
|
18-Jul-2013 |
Brian Carlstrom <bdc@google.com> |
Fix cpplint whitespace/blank_line issues
Change-Id: Ice937e95e23dd622c17054551d4ae4cebd0ef8a2
|
| 1754938e68bf53d674ffac364336a5dd2f3a60f0 |
|
16-Jul-2013 |
Elliott Hughes <enh@google.com> |
Remove an assertion that JDWP packets are small.
Now we support longer allocation tracker runs, it's possible
to collect more than 1MiB of data.
Equivalent to dalvik patch 75978b1e139da312515ec07022d47ac615615d1b.
Bug: 9871848
Change-Id: Id2134788b2815172d91d0ebad92198f0d2898442
|
| 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
|