Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8008678
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/
Summary:
The pseudo-strings are currently not supported in reconstitution of
constant pool.
This is an explanation from John Rose about what the pseudo-strings are:
"We still need "live" oop constants pre-linked into the constant
pool of bytecodes which
implement some method handles. We use the anonymous class
pseudo-string feature for that.
The relevant code is here:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/tip/src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java
These oops are what "pseudo-strings" are.
The odd name refers to the fact that, even though they are random
oops, they appear in the constant pool
where one would expect (because of class file syntax) to find a
string."
...
If you really wanted to reconstitute a class file for an anonymous
class, and
if that class has oop patching (pseudo-strings), you would need
either to (a) reconstitute the patches array
handed to Unsafe.defineAnonymousClass, or (b) accept whatever odd
strings were there first, as an approximation.
The "odd strings" are totally insignificant, and are typically
something like "CONSTANT_PLACEHOLDER_42"
(see java/lang/invoke/InvokerBytecodeGenerator.java)."
Reconstitution of the ConstantPool is needed for both the JVMTI
GetConstantPool() and RetransformClasses().
Finally, it goes to the ConstantPool::copy_cpool_bytes().
The problem is that a pseudo-string is a patched string that does
not have
a reference to the string symbol anymore:
unresolved_string_at(idx) == NULL
The fix is to create and fill in a map from JVM_CONSTANT_String cp
index to the JVM_CONSTANT_Utf8 cp index
to be able to restore this assotiation in the
JvmtiConstantPoolReconstituter.
Testing:
Run:
- java/lang/instrument tests
- new jtreg test (see webrev) that was written by Filipp Zhinkin
Thanks,
Serguei
