Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci (original) (raw)
mandy chung mandy.chung at oracle.com
Thu Dec 14 19:29:28 UTC 2017
- Previous message: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
- Next message: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 12/12/17 5:29 PM, John Rose wrote:
On Dec 12, 2017, at 5:24 PM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> wrote:
as per getByteCodeIndex() it needs to be able to store "-1" to indicate no-bci? Yes, that's the essential requirement, to encode a "none" value. FWIW, one natural way to do that here would be to make the int field @Stable and have the accessor return one less than the stored field value. Then, by the rules of @Stable, the field starts out at the logical value of -1, and can transition to a valid BCI if patched to a non-zero value in the range 1..(2^16).
Thanks for suggesting @Stable that would help this case. I can't understand why the field has to be patched with non-zero value. Is this something special requirement for @Stable?
Making it "final" and initialized to -1 is not too terrible either, although that creates some tech. debt we need to discharge when upgrading finals to be trustable.
Mandy [1] http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt
- Previous message: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767
- Next message: [10] (S) RFR 8191788: add jdk.internal.vm.compiler to --limit-modules if -Djvmci.Compiler=graal is in the command line
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]