Re: Can @Stable (or something similar) be made accessible?

> On Jan 15, 2018, at 6:00 AM, Vladimir Ivanov > wrote: > > >> This isn’t much different from the already allowed fine tuning of memory >> model effects (e.g., observing stale values from a plain write). In those >> scenarios, as is the case with @Stable,

Re: Can @Stable (or something similar) be made accessible?

> On Jan 15, 2018, at 6:51 AM, Vladimir Ivanov > wrote: > > Jason, > > I wouldn't consider @Stable as a scalpel :-) > > It's heavily locked down for a reason: it wasn't designed for eventual > standardization, but as (1) an experiment in _multiple_ directions;

Re: Can @Stable (or something similar) be made accessible?

Jason, I wouldn't consider @Stable as a scalpel :-) It's heavily locked down for a reason: it wasn't designed for eventual standardization, but as (1) an experiment in _multiple_ directions; and (2) solution for immediate problems in java.lang.invoke. @Stable mixes (incomplete

Re: Can @Stable (or something similar) be made accessible?

No, it doesn't work that way. @Stable enables JIT to constant fold loads from fields/arrays (holding non-default values) whenever possible. After that JIT has a constant value at its hands. All other optimizations follows from that: range check before array store can be

Re: Can @Stable (or something similar) be made accessible?

This isn’t much different from the already allowed fine tuning of memory model effects (e.g., observing stale values from a plain write). In those scenarios, as is the case with @Stable, developers have to be aware of and honor the respective contract. It could be argued that bugs arising

Re: Can @Stable (or something similar) be made accessible?

-nonstatic-final-fields/ - Mail original - > De: "Aleksey Shipilev" <sh...@redhat.com> > À: "Jason Greene" <jason.gre...@redhat.com>, "core-libs-dev" > <core-libs-dev@openjdk.java.net> > Envoyé: Vendredi 12 Janvier 2018 11:3

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 11:28 AM Jason Greene wrote: > > > On Jan 12, 2018, at 6:50 AM, Vladimir Ivanov < > vladimir.x.iva...@oracle.com> wrote: > > > > -snip- > > > So, the worst case scenario is: a value written into @Stable > field/array is never visible in some code

Re: Can @Stable (or something similar) be made accessible?

> On Jan 12, 2018, at 6:50 AM, Vladimir Ivanov > wrote: > -snip- > So, the worst case scenario is: a value written into @Stable field/array is > never visible in some code no matter what you do. It can lead to nasty bugs > when different parts of program

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 7:50 AM, Vladimir Ivanov < vladimir.x.iva...@oracle.com> wrote: > Would you be so kind to explain how this breakage occurs? I can >>> understand that improper use of @Stable annotation may break the >>> intended semantics of a program, but to break the integrity of VM? I'm

Re: Can @Stable (or something similar) be made accessible?

Would you be so kind to explain how this breakage occurs? I can understand that improper use of @Stable annotation may break the intended semantics of a program, but to break the integrity of VM? I'm trying to imagine the scenario, but can't. One example might be a @Stable array field used with

Re: Can @Stable (or something similar) be made accessible?

On 01/12/2018 01:11 PM, Vitaly Davidovich wrote: On Fri, Jan 12, 2018 at 6:36 AM Peter Levart wrote: Hi Andrew, On 01/12/2018 09:47 AM, Andrew Haley wrote: On 12/01/18 04:33, Jason Greene wrote: The internal @Stable facility provides the desired semantics and

Re: Can @Stable (or something similar) be made accessible?

On Fri, Jan 12, 2018 at 6:36 AM Peter Levart wrote: > Hi Andrew, > > On 01/12/2018 09:47 AM, Andrew Haley wrote: > > On 12/01/18 04:33, Jason Greene wrote: > > > >> The internal @Stable facility provides the desired semantics and > >> precision, but it is heavily locked

Re: Can @Stable (or something similar) be made accessible?

Hi Andrew, On 01/12/2018 09:47 AM, Andrew Haley wrote: On 12/01/18 04:33, Jason Greene wrote: The internal @Stable facility provides the desired semantics and precision, but it is heavily locked down, with privileged code checks and export restrictions. Could this be made more accessible (or

Re: Can @Stable (or something similar) be made accessible?

On 01/12/2018 05:33 AM, Jason Greene wrote: > MethodHandle.invokeExact() can match the performance of direct invocation, > but it requires > constant folding to do so. Otherwise results are similar to Java > reflection(e.g [1]). > > While TrustFinalNonStaticFields can be used, it’s a

Re: Can @Stable (or something similar) be made accessible?

On 12/01/18 09:06, Laurent Bourgès wrote: > I already made my fields (& constants) final but it is not enough to let > hotspot trust totally my code, isn't it ? To some extent yes, to some extent no. HotSpot really does trust static final constants not to change, so @Stable won't help you with

Re: Can @Stable (or something similar) be made accessible?

Hi, I am the author of the Marlin renderer, integrated in both java.desktop & javafx.graphics modules. I wonder if such core annotations @Stable @ForceInline ... could be allowed to such openjdk modules in order to improve performance. Marlin already uses jdk.internal.Unsafe but @Stable looks

Re: Can @Stable (or something similar) be made accessible?

On 12/01/18 04:33, Jason Greene wrote: > The internal @Stable facility provides the desired semantics and > precision, but it is heavily locked down, with privileged code > checks and export restrictions. Could this be made more accessible > (or perhaps a variant restricted to just final fields)?

Can @Stable (or something similar) be made accessible?

MethodHandle.invokeExact() can match the performance of direct invocation, but it requires constant folding to do so. Otherwise results are similar to Java reflection(e.g [1]). While TrustFinalNonStaticFields can be used, it’s a sledgehammer where a scalpel is really be more appropriate. The