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

Peter Levart peter.levart at gmail.com
Tue Aug 13 09:17:59 UTC 2019

Hi Mandy,

Just a question...

On 8/12/19 10:24 PM, Mandy Chung wrote:
> Having a second thought, I'm keeping @Stable bci field while zero 
> indicates an invalid BCI that makes it obvious that this field will be 
> updated.  VM will set StackFrameInfo::bci to value+1.
> http://cr.openjdk.java.net/~mchung/jdk14/8193325/webrev.03/
> Mandy

What are you trying to achieve with @Stable annotation?

If you were hoping for eventual optimization by JIT (i.e. constant 
folding) then this would only be effective if JIT could prove that the 
reference to the StackFrameInfo instance can also be constant folded. 
This is very unlikely considering the use cases of StackFrameInfo 
objects (results returned by StackWalker API). There are currently no 
other optimizations that I know of that would pertain to @Stable annotation.

If you were hoping to achieve some kind of "safer" publication of 
StackFrameInfo instances (like for example when the fields are final and 
initialized in the constructor) then @Stable is not a replacement for 
final. Even if you declared bci as final, its effective value is 
assigned in the VM after constructor is finished. So the JMM rules for 
final fields can not apply here. So it is my belief that neither placing 
@Stable nor final on the bci has any desirable effect. I would just 
leave it as plain instance field. I do like the zero default value of it 
and corresponding +/-1 offset computations in the getter and 
initialization code. If there is a data race when publishing 
StackFrameInfo objects unsafely to other threads, let there be only two 
values that are observable instead of three. BTW the unsafe publication 
applies not only to bci value but to the whole instance referenced by 
the 'memberName' field. The field is final and initialized in the 
constructor, but the MemberName instance is modified afterwards...

So let's not pretend publishing StackFrameInfo via data race is safe 
(like for example String objects). And I think it is not critical to be 
safe - no security decisions are being made on the StackFrameInfo 
objects' content, right?

Regards, Peter

More information about the core-libs-dev mailing list