Request for reviews (L): 6939203: JSR 292 needs method handle constants

John Rose john.r.rose at oracle.com
Tue Jun 8 21:59:12 PDT 2010


On Jun 8, 2010, at 9:12 PM, Tom Rodriguez wrote:

>> It looks like it only reads indexes (e.g., of getfield) in big-endian order; CP cache indexes are in native order.  Also, the code which uses the CP cache indexes does not seem to exist in places like GenerateOopMap.
> 
> I thought it always read in native order.  If that weren't the case then nothing would work, right?

The bytecode parsing is done by agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java in network order like this:

  /** Fetches a 16-bit big-endian ("Java ordered") value from the
      bytecode stream */
  public short getBytecodeShortArg(int bci) {
    int hi = getBytecodeOrBPAt(bci);
    int lo = getBytecodeOrBPAt(bci + 1);
    return (short) ((hi << 8) | lo);
  }

But... the bytes get swapped later in agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithCPIndex.java :

  protected int indexForFieldOrMethod() {
     ConstantPoolCache cpCache = method().getConstants().getCache();
     // get ConstantPool index from ConstantPoolCacheIndex at given bci
     int cpCacheIndex = index();
     if (cpCache == null) {
        return cpCacheIndex;
     } else {
        // change byte-ordering and go via cache
        return cpCache.getEntryAt((int) (0xFFFF & VM.getVM().getBytes().swapShort((short) cpCacheIndex))).getConstantPoolIndex();
     }
  }

So I need to teach interpreter.BytecodeLoadConstant to swap indexes and check the CP cache...

-- John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20100608/b1ae4434/attachment-0001.html 


More information about the hotspot-compiler-dev mailing list