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

Gregg,

You've been involved off-and-on in the concurrency and JMM discussions for
over 20 years, if I recall correctly.

Are you proposing that an existing optimization now be disallowed? Is this
a new proposal (from you), or has your argument changed?

(For example, now you are arguing that our understanding of Java's intended
audience is different than it was 20+ years ago?)


On Tue, Jul 20, 2021, 12:29 PM Gregg Wonderly via Concurrency-interest <
[email protected]> wrote:

> Andrew, I appreciate all of the details you enumerate below about the
> design of Java and how concurrency with multi-threading is a primary design
> element.  The reference hoist has nothing to do with that though.  It has
> to do with optimizing the execution time of a block of code.  Yes, the
> analysis takes all the details of concurrent access into consideration
> around code paths of this thread, able to reach back into the class in some
> form.  But that analysis is totally based on the ‘volatile’ nature of the
> value, not simply on the fact that we are in a language that provides APIs
> that allow multi-threading to work.
>
> I understand that the specifics seem integrated.  But my perspective is
> still that this reference hoist is assuming something that is so difficult
> to prove and variable based on what can be proved, that it’s an alarming
> side effect that is a surprise, more than it is a discernible behavior
> without extensive knowledge to all the implementation details which control
> when the hoist can actually occur.  Yes, that is what optimization is
> about, but the reality is that this optimization breaks the logic of the
> application and this is observable even in a debugger because of the logic
> change due to the hoisted read.  Other language compilers have over decades
> of development broken code due to mis-architected optimizations and we’ve
> not left them in.
>
> The contention I am sensing revolves around the fact that this single
> optimization would appear to be something that everyone is relying on to
> solve lots of performance problems.  In days gone by of C and C++
> programming, block-level, copy-of-value declarations were used as a moment
> to copy needed immutable references into block level values as a form of
> optimization of reference.  Things like
>
> SomeType val;
> if( ( val = externVal) != null ) {
> …lots of references to val...
> }
>
> As a general non-locking mutation scheme, copy and replace (via CAS)
> reference strategies are ever present in concurrent systems, to avoid
> locks.  There’s just so many things that are done explicitly and provide
> such better documentation than a compiler optimization does.
>
> The recurring counter point over the years, has been that experienced
> software developers can know why this occurs and will be able to readily
> fix the problem.  Really, believing that as a precursor to inaction, I
> feel, is a pretentious attitude that has caused a lot of people to not
> participate in many discussions.  It speaks to the belief that one can and
> does know everything, and that’s the only way to be a real software
> developer.  I’ve tried to have this discussion for years in a productive
> way.  But repeatedly, we arrive at “those are not real developers and so we
> don’t care about their problems” or “this is not a big problem, only some
> ignorant want-to-be programmers have this problem” so why should anyone
> care about them.
>
> It’s really a privilege for all who spend time on this level of software
> construction and have the knowledge to understand all the details that are
> discussed in this group and amongst people of this caliber of knowledge.
> Declaring it somehow required and achievable by all, is problematic, and
> that’s what I am continuing to stress.  Software doesn’t have to appear to
> be magic.  The notion of least surprise (
> https://en.wikipedia.org/wiki/Principle_of_least_astonishment) is an old
> principle that has books written about it to try and illuminate the ideals
> of how we should consider system design for the users of those systems.
>
> There are countless examples of how “training” is a requirement before
> performing lots of tasks in jobs and in life in general.  It’s not the
> training that I am complaining about.  It’s the notion that this single
> optimization is something that breaks software systems in non-predictable
> ways because it’s a large scale software system inspection, not a local,
> recognizable optimization that the user somehow knows they purposefully
> requested.
>
> I am go to once again cease here because I appear to be pushing buttons
> with my conversation mode and I am really not trying to make people made or
> defensive.  At some level these are hard discussions to have, I get that,
> but I just really sense to much defensive posturing and so I really don’t
> believe that the discussion can happen without creating even more walls to
> have to figure out how to talk through.
>
> Gregg
>
> On Jul 20, 2021, at 5:41 AM, Andrew Dinn via Concurrency-interest <
> [email protected]> wrote:
>
> On 19/07/2021 22:39, Gregg Wonderly via Concurrency-interest wrote:
>
> Thanks for you comments.   I am still trying to assert that the problem is
> this kind of assumption about people writing the code, actually being
> trained software engineers.  Instead, think of them as self taught coders.
> People who only every wrote “basic” or “vb” style integrations with just
> some knowledge that threads even exist, let alone, as in this case, knowing
> that the AWT event queue is involved and that there are threads (or more in
> the case of dialogs and other blocking actions) reaping events from the
> queue and dispatching them into your code.  Even the term callback or
> listener, for these people, doesn’t invoke any picture of “two” things
> working together.
>
>
> And I am still trying to assert that we should not hobble the language
> implementation to cater for that category of 'programmer' (rabbit ears de
> rigeur). Java has been specified and implemented for use by skilled and
> knowledgeable professionals. That includes knowing about and having the
> skill to deal with the presence of multi-threading as a core element of the
> language, with all its attendant complexities.
>
> Of course, as a Java implementor I make no assumption that all those who
> use Java will be skilled, knowledgeable professionals. What I do assume is
> that I don't have to take the concerns or failings of unskilled or ignorant
> 'would-be' coders into account.
>
> By the way, I believe you are having your cake and eating it in the way
> you present your arguments here. You cited an example program as simple to
> understand and behaving as expected until you remove some logging code to
> simplify it and suddenly ... oh,. how surprising, a non-volatile access
> gets hoisted! At which point this simple to understand code becomes
> incomprehensible to the average reader.
>
> In truth, if you know how to read the different versions of this code with
> an awareness that Java is a multi-threaded language the complexity is never
> absent. The surprise you describe is prima facie evidence that your posited
> average reader is not reading the code correctly, whether in the original
> or reduced version. They just think they understand it.
>
> regards,
>
>
> Andrew Dinn
> -----------
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
>
> _______________________________________________
> 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
>

_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest