RFR JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767

[Aleksey Shipilev]

On 8/9/19 10:19 PM, Mandy Chung wrote:
> An earlier version of this patch was reviewed [1] but I
> didn't get back to explore the other approach.  I rebase
> the patch and take out the hotspot change which will be
> covered by JDK-8229375:
> 
> http://cr.openjdk.java.net/~mchung/jdk14//8193325/webrev.01

I wonder if bci=-1 is meaningful, and should be returned when BCI is not available. After this
patch, it would be converted to 65536?

Anyhow, I am looking at current field layout of StackFrameInfo and wonder why not expand bci to the
proper int, which would avoid both this and JDK-8229375? There seems to be the non-taken 2-byte gap
before oop fields that bci can extend into without increasing the object size.

java.lang.StackFrameInfo object internals:
 OFFSET  SIZE                          TYPE DESCRIPTION                               VALUE
      0    12                               (object header)                           N/A
     12     2                         short StackFrameInfo.bci                        N/A
     14     2                               (actually, injected "version"?)
     16     1                          byte StackFrameInfo.flags                      N/A
     17     3                               (alignment/padding gap)
     20     4              java.lang.Object StackFrameInfo.memberName                 N/A
     24     4   java.lang.StackTraceElement StackFrameInfo.ste                        N/A
     28     4                               (loss due to the next object alignment)
Instance size: 32 bytes
Space losses: 5 bytes internal + 4 bytes external = 9 bytes total

-- 
Thanks,
-Aleksey