[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    RFR (S) 8008678: JSR 292: constant pool reconstitution must support pseudo strings
From:       "serguei.spitsyn () oracle ! com" <serguei ! spitsyn () oracle ! com>
Date:       2014-11-26 8:59:56
Message-ID: 5475968C.40800 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]