Re: Are there real use cases with the Java access modes?

Consider for a moment if Java was originally designed with the current 
memory model, and that all fields were effectively volatile by default. 
This would mean that the loop problem that you identified would never 
surface, which is a good thing.

One problem is now solved, but perhaps new problems would emerge? The 
first problem that I can think of is that this doesn't magically make 
code thread-safe. The cost is performance, and there's no real benefit 
except in a few cases. The bigger problem is "premature optimization".

As soon as someone discovers that declaring fields as non-volatile 
offers performance benefits, then this ends up becoming best practice, 
and new thread safety issues emerge that never should have.

The best practice these days is for most programmers to never declare 
volatile fields in the first place, because it implies that they're 
doing magic stuff with threads and they might not do it correctly. 
Unlike Java 1.0, there's plenty of frameworks that take care of thread 
safety nicely without having to declare fields as volatile or make 
methods synchronized. Work queues fall into this category, for example.

Your concern seems to be with regard to Java desktop apps, and this is 
fair. The Java desktop API (AWT/Swing) was designed without proper 
consideration for threads, and it's quite a mess as a result. A lot has 
been learned since then, and the desktop API is in need of a major 
refresh. That is, it needs to be completely redesigned to incorporate 
the lessons learned over the past 25 years. If a new design requires 
that fields need to always be volatile, then it's a failure too.

By the way, I suspect that most people on this mailing list (including 
me) usually write server-side code, and so we don't have a proper 
understanding of how the desktop API can sometimes be a burden. So when 
we hear someone suggesting that fields behave as volatile by default, we 
wonder if this would solve any of the problems we've ever encountered. I 
can't really think of any, but then this is probably because the 
server-side has a richer set of frameworks to use.


On 2021-07-18 10:54 AM, Gregg Wonderly via Concurrency-interest wrote:
> Good software design always includes the notion of least surprise.  In 
> which other languages are there examples of Volatile or other 
> optimizations that rewrite code to be incorrect based on what the code 
> reads?  There is literally no advantage to this rewrite.  Developers can 
> write this code exactly if they believe it is beneficial to them.  But 
> having it done by default, is a giant surprise and in fact drives people 
> away from Java because this looks like a bug, and the compiler still 
> contains zero warnings about volatile optimizations that may change 
> logic to not be what the code reads.
> 
> Literally every single volatile read escape optimization should be 
> issuing warnings to the user that their code will not be executed more 
> than once.  You continue to insist that this is rare code while it is 
> the single most common mechanism for controlling UI actions.  Whether 
> it’s a boolean or an object reference, this optimization is a huge 
> detriment to new developers trying out Java desktop apps.
> 
> Gregg Wonderly
> 
> Sent from my iPhone
> 
>> On Jul 18, 2021, at 2:35 AM, Alex Otenko <[email protected]> 
>> wrote:
>>
>> 
>> The simple truth is that there are more ways to write incorrect code 
>> than there are ways to write correct code. Complex state changes 
>> cannot be assumed to work correctly, when done concurrently.
>>
>> And the things that count for "complex" - anything beyond a single bit 
>> flip 0->1, and never back 1->0, is complex.
>>
>> There is no point in forbidding one optimisation for the sake of one 
>> type of system where that's the only problem.
>>
>> Alex
>>
>> On Sun, 18 Jul 2021, 05:13 Gregg Wonderly via Concurrency-interest, 
>> <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>>     Yes this was changed at the sane time the JMM defined  and caused
>>     implementation of volatile to happen.
>>
>>     While this is legal because of the JMM, it causes broken code to
>>     happen without the user really understanding why it could happen
>>     and that it will happen.  It’s different in significant ways from
>>     cache coherency, and it worked prior to JDK1.5.  I still believe
>>     that volatile creates a giant surprise.  This is an optimization
>>     behavior that “breaks” code without the user electing to have such
>>     an optimization performed!
>>
>>     The default variable declaration should be volatile and a
>>     different mechanism should be necessary to get non-volatile
>>     optimizations to happen.  A user should never, ever, be able to
>>     write non-working code using default language constructs.
>>
>>     Look at the past examples in C-Language and C++ etc.  Things like
>>     Register optimizations and many other constructs required the user
>>     to break their code, rather than that being the default behavior!
>>
>>     Gregg Wonderly
>>
>>     Sent from my iPhone
>>
>>>     On Jul 17, 2021, at 5:05 PM, Shuyang Liu <[email protected]
>>>     <mailto:[email protected]>> wrote:
>>>
>>>     Thanks you!
>>>
>>>      I guess this is before Java 9? So I think “nonVolatileRefExpr”
>>>     is equivalent to a plain access in this case. The compiler
>>>     probably identified it as a local access since it is not marked
>>>     as volatile (then its indeed equivalent to an infinite loop,
>>>     which makes the transformation valid). Do you know if there’s any
>>>     applications/bug report with this pattern?
>>>
>>>     Best Regards,
>>>     Shuyang
>>>
>>>>     On Jul 17, 2021, at 1:46 PM, Gregg Wonderly <[email protected]
>>>>     <mailto:[email protected]>> wrote:
>>>>
>>>>     One of the standing problems I have is optimizations around
>>>>     non-volatile value references.  Currently, there are visibility
>>>>     optimizations that turn
>>>>
>>>>     while( nonVolatileRefExpr ) {}
>>>>
>>>>     Into
>>>>
>>>>     if( nonVolatileRefExpr ) { while( true ) {} }
>>>>
>>>>     Which creates infinite loops.  This makes one of the most common
>>>>     types of applications written in Swing to fail to work as the
>>>>     code is written.
>>>>
>>>>     Gregg Wonderly
>>>>
>>>>     Sent from my iPhone
>>>>
>>>>>     On Jul 17, 2021, at 4:33 PM, Shuyang Liu via
>>>>>     Concurrency-interest <[email protected]
>>>>>     <mailto:[email protected]>> wrote:
>>>>>
>>>>>     
>>>>>     Hello,
>>>>>
>>>>>     My colleagues and I have been working on a formal model for the
>>>>>     Java access modes that is added since Java 9 [1]. Are there any
>>>>>     popular use cases of access modes in real world
>>>>>     applications/frameworks/libraries? We would like to see how our
>>>>>     current formal model works in real examples.
>>>>>
>>>>>     Thanks you,
>>>>>     Shuyang Liu
>>>>>
>>>>>     [1]. Using JDK 9 Memory Order Modes
>>>>>     http://gee.cs.oswego.edu/dl/html/j9mm.html
>>>>>     <http://gee.cs.oswego.edu/dl/html/j9mm.html>
>>>>>     _______________________________________________
>>>>>     Concurrency-interest mailing list
>>>>>     [email protected]
>>>>>     <mailto:[email protected]>
>>>>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     [email protected]
>>     <mailto:[email protected]>
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>     <http://cs.oswego.edu/mailman/listinfo/concurrency-interest>
>>
> 
> _______________________________________________
> Concurrency-interest mailing list
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest