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

> On Jul 19, 2021, at 9:25 AM, Andrew Haley via Concurrency-interest <[email protected]> wrote:
> 
> On 7/19/21 3:06 PM, Gregg Wonderly via Concurrency-interest wrote:
>> I am specifically against the single optimization I illustrated that rewrites code to be non-logically executed, without the user being aware of this happening and not being warned that an optimization has potentially made the logic of the application not work as expected.
> 
> That single optimization is no more than hoisting a memory load. It's
> one of the most common optimizations there is. It probably happens
> many times in every moderately complex method. It's not some kind of
> weird "let's turn this into an infinite loop" optimization.

Because it's in logic control code, it becomes quite visible as “unknown” behavior that the explicit code elements don’t illustrate, in any way, as the desired behavior.  If volatile was the default, and the user had to instead declare non-volatile desires with @nonvolatile or some other declaration (no new keywords is a problem), then this optimization would be documented by the code structure and keyword/feature use.  I get that no-one really wants to be faced with this, yet, when the JMM was released, everyone was faced with it.

> For every non-volatile field load, in the absence of synchronization
> actions, it is entirely correct and proper to hoist the result of that
> load into a register, or propagate its value some other way. This is
> common in many programming language implementations, and is not going
> to change. It is a very important optimization.

There are countless data sharing APIs that suggest that non-volatile should never be something a user experiences, implicitly.  These APIs have to exist to “fix” problems with non-volatile being a default element of the language operations by explicitly controlling the moment that “volatile” data sharing occurs.  It’s an interesting history of concurrency design/development.   When java was released with just Vector and HashMap, we of course were all unexcited by the fact that there wasn’t ’non-volatile’ storage implementations that would make single user (thread) access fast and efficient.  Java “servers" suffered scaling pain from all kinds of things not “finished”.
 
Why would a user write conditional logic, intending that the control be with a non-volatile value?  A warning to the user on compilation would be the most helpful thing that could occur.  But we don’t have that to help people understand that their software logic is not being executed as expected.

I completely understand that this is now history, unfortunately.   But I still feel that this single thing about the Java language provides one of the most fragile elements of multi-threaded application behavior because it happens implicitly.

Gregg Wonderly

> 
> -- 
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> 
> _______________________________________________
> 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