| ac5fea049d898713bb5802141af2ee3d59ee592d |
|
23-Mar-2018 |
Alex Light <allight@google.com> |
Remove unneeded ScopedGCCriticalSections from openjdkjvmti.
We used ScopedGCCriticalSections in many parts of the openjdkjvmti
often unnecessarily.
We removed a totally unneeded GCCriticalSection that was acquired when
modifying the instrumentation listeners.
We also removed RequestGCSafeSynchronousCheckpoint and the change to
use GcRoots instead. We added RequestGCSafeSynchronousCheckpoint as a
way to prevent the GC from running when we are doing some JVMTI
operations on other threads. This could interact with running GCs in
non-trivial ways, potentially causing deadlocks in some situations.
This changes the code to instead use read-barriers and GcRoots to
ensure that we do not read data from the wrong gc space.
In order for this to work correctly we need to make sure that we are
only ever reading the GcRoots from the thread that eventually needs
the reference. This required some re-writing of the checkpoint
closures since they would often just call AddLocalReference on
non-local Thread objects.
Changes to Thread::RequestSynchronousCheckpoint and art::Barrier were
needed in order to allow this all to work since we needed to ensure
that the requesting thread did not suspend as the checkpoint was being
run.
This is a partial revert of commit 7585b91bfc77b8.
Bug: 67838964
Bug: 76003243
Test: use gapid
Test: ./test.py --host -j50
Test: ./art/tools/run-libjdwp-tests.sh --mode=host
Merged-In: I26d871089829639eccb973cecc315194f7bcf681
Change-Id: I26d871089829639eccb973cecc315194f7bcf681
(cherry picked from commit 318afe6c3ac1e734adbd769bbf22b8c7e373e80b)
|
| 57943810cfc789da890d73621741729da5feaaf8 |
|
07-Dec-2017 |
Andreas Gampe <agampe@google.com> |
ART: Replace base/logging with android-base/logging
Replace wherever possible. ART's base/logging is now mainly VLOG
and initialization code that is unnecessary to pull in and makes
changes to verbose logging more painful than they have to be.
Test: m test-art-host
Change-Id: I3e3a4672ba5b621e57590a526c7d1c8b749e4f6e
|
| 9311297a763d9d6cf6059f110a9aa136c0c8d81f |
|
13-Nov-2017 |
Alex Light <allight@google.com> |
Make agent threads retain their thread names
We were previously ignoring the thread-names given to agent threads.
This could make debugging issues difficult as every thread was called
"JVMTI Agent thread". Change the RunAgentThread code so instead we
will use the same thread-name as the java thread.
Bug: 68839405
Test: ./test.py --host -j50
Change-Id: Ifdd58e4eebc1877bde0ba49d4fbedbd3935b312f
|
| d9aff1372e6a2f573b14d124f3d6f5305bdc6080 |
|
31-Oct-2017 |
Alex Light <allight@google.com> |
Revert "Revert "Prevent races with GC when transferring objects between threads""
This reverts commit e5179ce0ca8becf34ba6e7b2f3988874fe647c26.
Reason for revert: Fixed issues with:
Checkpoint flag set without pending checkpoint in parent CL.
Bug: 67838964
Test: ./test.py --host -j50
Change-Id: I7622f9c18866b58ee3cbd9f4fe38a29b2cf84a88
|
| e5179ce0ca8becf34ba6e7b2f3988874fe647c26 |
|
31-Oct-2017 |
Alex Light <allight@google.com> |
Revert "Prevent races with GC when transferring objects between threads"
This reverts commit 7585b91bfc77b8e4b821ccfa716fa86e46455275.
Reason for revert: Seems to be causing fatal error:
Checkpoint flag set without pending checkpoint
Change-Id: I98ea653e629d73e854907115583afed3ed5ac68e
Test: None.
Bug: 67838964
|
| 7585b91bfc77b8e4b821ccfa716fa86e46455275 |
|
30-Oct-2017 |
Alex Light <allight@google.com> |
Prevent races with GC when transferring objects between threads
We could have races with the GC when JVMTI code transfers a local
reference from one thread to another. This race would happen if a GC
was currently underway causing an unmoved reference to be transferred
to a thread that has already fixed up all of its references. This
meant that the receiving thread would now have a reference belonging
to the from-space on its stack.
This could cause memory errors and CHECK failures.
To fix this we make sure to run all checkpoints where local references
might be transferred in a GC-critical-section.
We also needed to fix a too-strict check in the method verifier where
we were incorrectly asserting that suspension be allowable when in
fact it was not necessary in all cases.
Test: ./test.py --host -j50
Bug: 67838964
Change-Id: Ib9166cc233d3c1b488864c0aff33246a3f99e436
|
| 373a9b5c718a45ac484afcf4fe6ce84f4bb562b3 |
|
18-Oct-2017 |
Andreas Gampe <agampe@google.com> |
ART: Depend on libnativehelper headers only
Depend on header-only versions where possible. Move projects
excluding libart to libnativehelper_header_only.
Bug: 65522645
Test: mmma art
Change-Id: I53dd3b2a97e94ee685f72de007ed3858f7f5c6b6
|
| 739bf72ccb22794bc65203aa4824dba737cadd72 |
|
20-Oct-2017 |
Alex Light <allight@google.com> |
Make RunAgentThread ensure thread attach is possible.
We need to ensure that we will be able to actually attach a thread
before we try to create the new agent thread. Previously we were
simply asserting that Attach succeeds and returning instantly. This
could lead to CHECK failures if we were unlucky enough to race with
the runtime destructor.
Test: ./test.py --host -j50
Bug: 68052586
Change-Id: Ib303260f4029346bb0c52c969c69ac54f14cce22
|
| b1e31a8337b9cce2f3160a972123886b355dce27 |
|
05-Oct-2017 |
Alex Light <allight@google.com> |
Change RequestSynchronousCheckpoint to release thread_list_lock_
The RequestSynchronousCheckpoint function in some cases needs to
release the thread_list_lock_ as it waits for a checkpoint to be
executed. This means that the thread being checkpointed might be
deleted. Previously it was not obvious this was the case since the
thread_list_lock_ seemed to be held throughout the execution of the
method.
In order to prevent bugs we make RequestSynchronousCheckpoint
explicitly release the thread_list_lock_ when executed, meaning code
will be aware that threads might die during its execution.
Bug: 67362832
Test: ./test.py --host -j50
Change-Id: I1cbdf7660096dc1908b0eeabc1062447307bc888
|
| 597adad749499bc2da85851273e7623f6b249d1e |
|
17-Oct-2017 |
Alex Light <allight@google.com> |
Fix GetThreadState with threads in kNative.
We were always returning JVMTI_THREAD_STATE_WAITING for threads in the
kNative state. To prevent any similar problems from happening in the
future we changed it so all thread-states are explicitly enumerated
and handled in a switch statement.
Test: ./test.py --host -j50
Bug: 67784165
Change-Id: I6646b36aa36cb4671bf95777aefc5c88b659e90f
|
| 54d39dc42630cd83f2d1bec5704805febb894819 |
|
26-Sep-2017 |
Alex Light <allight@google.com> |
Implement JVMTI can_signal_thread capability.
Implements the JVMTI can_signal_thread capability and all associated
methods and behaviors. This includes both the StopThread and
InterruptThread functions.
This CL contains the tests for the previous CL.
Test: ./test.py --host -j50
Test: stress --cpu 59 && while ./test/run-test --host 1934; do; done
Bug: 62821960
Bug: 34415266
Change-Id: I7b6fc37da0d2673caa993e486f078cf129d74c0f
|
| 7ddc23d9ea95848724754eae270a0a1ce108edb9 |
|
23-Sep-2017 |
Alex Light <allight@google.com> |
Consolidate all JVMTI jthread decoding.
We had multiple places where we would decode jthreads. This meant that
we did not always check all required constraints before using it. This
CL consolidates all jthread decoding into the
ThreadUtil::GetNativeThread function and adds a helper
ThreadUtil::GetAliveNativeThread function to check the most common
requirements on jthreads passed to JVMTI.
Bug: 66709480
Test: ./test.py --host -j50
Test: cd openjdkjvmti && git grep -W FromManagedThread
Change-Id: Ib6f4bc8510012e0332831bea67e1842a49092917
|
| ba461c3c5b588b0b65d3cc99aa12fe46a673962c |
|
22-Sep-2017 |
Alex Light <allight@google.com> |
Ensure GetThreadState works with Thread subtypes
We were incorrectly assuming that Thread has no subclasses. This is
not accurate.
Bug: 66704836
Test: ./test.py --host -j50
Change-Id: I4abd85b6c4e6add6d62854adb4f8912777292315
|
| 77fee87b262e969b29a9ac121a8bcbf87b68d9ce |
|
05-Sep-2017 |
Alex Light <allight@google.com> |
Add support for JVMTI monitor events.
Adds support for the JVMTI can_generate_monitor_events capability and
all associated events. This adds support for the
JVMTI_EVENT_MONITOR_WAIT, JVMTI_EVENT_MONITOR_WAITED,
JVMTI_EVENT_MONITOR_CONTENDED_ENTER, and
JVMTI_EVENT_MONITOR_CONTENDED_ENTERED events.
Bug: 65558434
Bug: 62821960
Bug: 34415266
Test: ./test.py --host -j50
Change-Id: I0fe8038e6c4249e77d37a67e5056b5d2a94b6f48
|
| 23aa74818272a9d659414536324ae9133ecb8743 |
|
16-Aug-2017 |
Alex Light <allight@google.com> |
Fix issue with RawMonitors around thread suspension.
Investigation of real-world JVMTI agents revealed that some rely on
the RawMonitorEnter function acting as a Java suspend point. If it
fails to act as one the agent could end up deadlocked.
Test: ./test.py --host -j50
Bug: 62821960
Bug: 34415266
Change-Id: I3daf5c49c1c9870e1f69eebfd4c6f2ad15224510
|
| 1d8a9741d2979d09a21942fbf9107d212ce2511b |
|
17-Aug-2017 |
Alex Light <allight@google.com> |
Fix interaction of VMInit and ThreadStart events.
Real world agents require that one is able to create, and run, new
threads while the VMInit event is still being executed. Further, these
require that ThreadStart events can occur concurrently with the VMInit
event. This CL enables this behavior and adds a test for the
interaction of these two events.
Test: ./test.py --host -j50
Bug: 62821960
Bug: 34415266
Change-Id: I305f1ce3f1df9bf5a7e33027e0724f5fbac5c0f1
|
| 06c42a571358b5e5adb69104b183af8f32f4c07d |
|
26-Jul-2017 |
Andreas Gampe <agampe@google.com> |
ART: Move openjdkjvmti to art/
Move libopenjdkjvmti out of the runtime directory. Let's not
pollute the runtime library.
Test: m test-art-host
Change-Id: Idb6b9cebcd61777bd3200437a2ae584a63a4a341
|