| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
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
|
