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