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
