Possible bug in StackFrameInfo#getByteCodeIndex?

Martin Buchholz martinrb at google.com
Tue Dec 12 19:08:15 UTC 2017


Out of curiosity, I looked more at StackFrameInfo, and saw:

short bci is final and is only ever assigned to -1 in java code.  What's up
with that?  Ohh, it seems to be magically frobbed in hotspot:

void java_lang_StackFrameInfo::set_bci(oop element, int value) {
  element->int_field_put(_bci_offset, value);
}

BUT: bci should not be final if hotspot magic is frobbing it.  Can we add a
comment explaining the magic?  Also set_bci seems to disagree about the
type of bci - it's trying to set an int field, but bci is a short!

Also, I expected "int value" above to be "jint value" - it's a java type!

I would prefer bci to be a java int, not short, so that it can hold all
possible bytecode index values in a natural way, together with -1 for
"invalid".  Right now, -1 is ambiguous - it might mean bci == 65535.

Also, I see
    private final byte RETAIN_CLASS_REF = 0x01;
Shouldn't that be static?


More information about the core-libs-dev mailing list