| Age | Commit message (Collapse) | Author |
|
DexPCMove events should happen before any ExceptionCatch events. This is
usually not noticeable but if the catch handler enables single stepping
then we would again break at the catch statement which isn't expected.
Bug: 333446719
Test: art/test.py 2282
Change-Id: I570399dbc057a7a85979839cf8c1dad0787816b3
|
|
This reverts commit db0551d164783866acf0cdcf9a7741ee6f21f0f2.
Reason for revert: Updated test to a use method declared in the Test
class instead of the hidden java.lang.classForName.
Change-Id: Ifa725b5465163fa73e4808d87a2b205b92aa110f
|
|
This reverts commit b42b645e26e206a2b1457cf9ea453b5021a873f5.
Reason for revert: Likely culprit for b/342131895 - verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Change-Id: Ic2724b90528b5a9e299e0df7d909be60d5c1e0eb
|
|
When we are returning from JNI with a pending exception we deoptimize to
correctly handle the exception. We missed reporting an unwind event for
the native method that was returning. Also adds a regression test for
this case.
Bug: 339662394
Test:art/test.py -t 989
Change-Id: I8336dc831e3801b8c0976a5588d1682363d10e64
|
|
Add structural redefinition extension function and event that mirror
the 'RedefineClasses' function and 'ClassFileLoadHook' event. The new
extension function is called
'com.android.art.class.structurally_redefine_classes' and the new
extension event is called
'com.android.art.class.structural_dex_file_load_hook'.
These extensions are the preferred way to use structural redefinition.
Like the standard 'RedefineClasses' multiple classes may be redefined
at a time.
The structural_dex_file_load_hook is triggered prior to the
can_retransform_classes ClassFileLoadHook. It is triggered on all
classes, even ones that cannot be structurally changed by
class-loading, class redefinition or by calling the RetransformClasses
function.
Calling 'structurally_redefine_classes' with new definitions that do
not require structural changes will fall back to non-structural
redefinition.
Test: ./test.py --host
Bug: 134162467
Change-Id: If4810930470c5c6509cf6db779910006e114b39f
|
|
This reverts commit 5a2301d897294ff4ee6de71f459dc2566dc3fa1a.
Bug: 134162467
Reason for revert: Relanding as unclear if issue is due to topic.
Change-Id: Ib1d1cf2e9132e30c9649b760ae9ae2d8ceacf843
|
|
This reverts commit c971eafeff43e4e26959a6e86b62ab0a8f1a6e1c.
Bug: 134162467
Reason for revert: Breaks on redefine-stress
Change-Id: I4e38da23d65b5b34b26b5ab537a3583328e078a4
|
|
This adds basic support for adding methods and fields to already
loaded classes using redefinition. This 'structural class
redefinition' is currently limited to classes without any virtual
methods or instance fields. One cannot currently structurally redefine
multiple classes at once nor will structural redefinition trigger the
standard redefinition events.
After structural redefinition all references to the old class, and its
fields and methods are atomically updated. Any memory associated with
the static fields of the old class is zeroed. Offsets for field access
might change. If there are any active stack frames for methods from
the redefined class the original (obsolete method) code will continue
to execute. The identity hash code of the redefined class will not
change. Any locks being held, waited or blocked on by the old class
will be transferred to the new class.
To use this feature the process must be debuggable and running with
-Xopaque-jni-ids:true.
For device testing use a wrap.sh that adds the following flags:
'-Xopaque-jni-ids:true -Xcompiler-option --debuggable -XjdwpProvider:adbconnection'
Structural redefinition only available using the
"com.android.art.UNSAFE.class.structurally_redefine_class_direct"
extension. This will not trigger the normal class-redefinition events.
Only one class may be redefined at a time.
NB There are still some holes in this potentially allowing obsolete
methods/fields to be visible. Most notably during jni-id, MethodHandle
and VarHandle creation as well as potentially other places in the
runtime. These holes will be closed by later CLs. Until then the
extension to access structural class redefinition will remain tagged
as UNSAFE.
Test: ./test.py --host --all-compiler
Bug: 134162467
Change-Id: I825d3a4bdb9594c0147223ae69f433ce9bbfc307
|
|
Add support for can_force_early_return jvmti capability. This allows
one to force java frames to exit early. Exited frames have all of
their normal locks released.
We implement this by modifying the existing method exit events to
allow one to modify the exit value during the callback. This is used
to implement ForceEarlyReturn by adding internal-only events that will
change the return value of methods once they return (using
kForcePopFrame) avoiding the need to modify the actual interpreter
very deeply. This also makes it simple to continue to use the standard
deoptimization functions to force the actual return.
In order to simplify book-keeping the internal event is refcounted,
not associated with any specific jvmtiEnv, and only settable on
specific threads. The internal event is added by the ForceEarlyReturn
function and then removed by the MethodExit event when we update the
return value.
Bug: 130028055
Test: ./test.py --host
Change-Id: Ifa44605b4e8032605f503a654ddf4bd2fc6b60bf
|
|
We share many common JVMTI test classes between our various JVMTI
tests. We have always shared them by simply copying the .java files to
any tests that need them. This leads to very large code-reviews and
requires manual work if we ever need to update any of the helper
files.
To ensure everything stays in sync this moves all classes to a single
test/ti-common directory that tests then contain symlinks into.
Test: ./test.py --host
Change-Id: I82238a63d281429196ed0e640e4a9ec3234d954c
|