JDK-8008678 : JSR 292: constant pool reconstitution must support pseudo strings
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-02-21
  • Updated: 2015-06-03
  • Resolved: 2015-01-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b50Fixed
Related Reports
Duplicate :  
Relates :  
Description
The pseudo-strings are currently not supported in reconstitution of constant pool.

It does not make sense to copy the whole email exchange here.
So, just some 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."
            and ...
"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 InvokerBytecodeGenerator::constantPlaceholder)."


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

This is the place that has to be fixed:

ConstantPool.cpp:
int ConstantPool::copy_cpool_bytes(int cpool_size,
      . . .
      case JVM_CONSTANT_String: {
        *bytes = JVM_CONSTANT_String;
        Symbol* sym = unresolved_string_at(idx);
        idx1 = tbl->symbol_to_value(sym);
        assert(idx1 != 0, "Have not found a hashtable entry");
        Bytes::put_Java_u2((address) (bytes+1), idx1);
        DBG(char *str = sym->as_utf8());
        DBG(printf("JVM_CONSTANT_String: idx=#%03hd, %s", idx1, str));
        break;
      }

The John's suggestion for odd strings is to use either the empty string,
or something slightly informative such as "patch#42", where 42 is the CP index.
Something like:
  if (sym == NULL) {
    str = "patch#42";
  }


Comments
The suggested fix is: http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/8008678-JVMTI-pseudo.1/
26-11-2014

Changed the priority to P3 as this needs to be fixed in the 8u too. I'm going to add a failing test for this issue, so that the L will have Mid impact: L=M
17-11-2014

ILW=MLH=P4, Mid impact (jsr-292 related potential issue), Low likelihood (no known failing tests), High - no known workaround.
23-10-2013

I've changed the priority to P3 as this is jsr-292 related issue and better to be fixed. It is not going to take much time, I think.
10-09-2013

Serguei, do you have a fix in the pipe for this? If not, then please remove the 8-target and target this as tbd_minor. P4 is much to low prio this late in the release cycle. Thanks! //T
10-09-2013

This is a comment from Coleen: "I think it needs more than this patch#42 symbol because the oop has to be carried forth from the resolved_references array in the old constant pool, and repatched into the new constant pool once the new resolved_references array is created. And I didn't follow what this this symbol hashtable was trying to do. It would be good to start with a test for this."
14-03-2013