Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci (original) (raw)

David Holmes david.holmes at oracle.com
Wed Dec 13 01:24:55 UTC 2017

Hi Mandy,

On 13/12/2017 10:42 AM, mandy chung wrote:

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193325/webrev.00/

This fixes the bug in hotspot that sets the bci field as int but it's of short type and also StackFrameInfo to return a proper bci value.  Coleen suggests not to change setbci to take jushort but instead do the cast as in the proposed fix.  The VM is in favor of C++ types and stop propagation of Java types.  bci is of int in VM implementation and so be consistent.

I must admit I'm unclear why the VM needs the BCI to be an int when logically it is a jushort, but perhaps, as per getByteCodeIndex() it needs to be able to store "-1" to indicate no-bci?

The fix itself seems fine, though if we're going to chop off the VM value at 16-bits perhaps we should assert that it isn't a value that requires > 16 bits?

Thanks, David

Mandy [1] mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050581.html

More information about the core-libs-dev mailing list