Possible bug in StackFrameInfo#getByteCodeIndex?

[mandy chung]

Good catch!  I agree that it should not be final and the constant field 
should be static. I will take JDK-8193325 and follow up this issue.

-1 is ambiguous but should be initialized to a valid index when filled 
by the VM.  We tried to keep it compact for footprint concern.  Anyway I 
will propose a patch.

Mandy

On 12/12/17 11:08 AM, Martin Buchholz wrote:
> 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?