summaryrefslogtreecommitdiff
path: root/test/jvmti-common/Redefinition.java
diff options
context:
space:
mode:
authorAlex Light <allight@google.com>2019-08-13 10:50:38 -0700
committerTreehugger Robot <treehugger-gerrit@google.com>2019-09-17 23:52:12 +0000
commitc971eafeff43e4e26959a6e86b62ab0a8f1a6e1c (patch)
treef8647487e7465712fd73118ceb89e13167a12648 /test/jvmti-common/Redefinition.java
parent1ba7e8c10af4e270864a417044244d63db53ccf5 (diff)
Basic structural redefinition support
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
Diffstat (limited to 'test/jvmti-common/Redefinition.java')
-rw-r--r--test/jvmti-common/Redefinition.java3
1 files changed, 3 insertions, 0 deletions
diff --git a/test/jvmti-common/Redefinition.java b/test/jvmti-common/Redefinition.java
index 56d2938a01..2ebce17686 100644
--- a/test/jvmti-common/Redefinition.java
+++ b/test/jvmti-common/Redefinition.java
@@ -88,4 +88,7 @@ public class Redefinition {
public static native void addCommonTransformationResult(String target_name,
byte[] class_bytes,
byte[] dex_bytes);
+
+ public static native void doCommonStructuralClassRedefinition(Class<?> target, byte[] dex_file);
+ public static native boolean isStructurallyModifiable(Class<?> target);
}