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
