> On Aug 20, 2018, at 12:23 PM, Andrew Haley wrote:
>
> On 08/20/2018 04:14 PM, Jason Greene wrote:
>
>> IMO departing from C semantics (non-zero = TRUE, zero = false)
>> offers little gain and will likely just lead to hard to catch
>> bugs. Even if the JNI deve
> On Aug 20, 2018, at 9:55 AM, Aleksey Shipilev wrote:
>
> On 08/20/2018 12:22 PM, Volker Simonis wrote:
>> So to summarize, my current view on this topic is:
>> - JNI functions returning a jboolean are only allowed to return
>> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcificat
> 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, developers have to be aware of and
> 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; and (2)
> solution for immedia
> 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 don't agree on observed value. It c
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
