Re: Amazon Graviton and implications for concurrent Java apps

I used it. Java pathfinder gives you false hope.

That is, if it finds races, they exist. If it doesn't, it is not a proof of
correctness.

For example, how to decide how many threads should be run in a test? Two?
It can be shown to be wrong for most locks.

More threads - more states that it cannot determine to be the same.

Alex

On Mon, 16 Mar 2020, 16:03 Nathan Reynolds via Concurrency-interest, <
[email protected]> wrote:

> Java Pathfinder is a great tool for finding races, hangs and deadlocks.
> It is a JVM written in Java.  It executes bytecode. Every time the
> bytecode accesses a shared variable, synchronizes, etc. then Java
> Pathfinder makes a schedule branch.  This means Java Pathfinder
> interleaves every possible thread ordering.  If a deadlock can happen,
> Java Pathfinder will reproduce the problem.
>
> With only 2 threads, the number of thread orderings can be exponential.
> Java Pathfinder keeps track of visited states and when two different
> interleavings are identical then the duplicates are no longer explored.
> However, do not attempt to run anything very large.  Typically, a single
> class is complex enough.
>
> https://en.wikipedia.org/wiki/Java_Pathfinder
>
> -Nathan
>
> On 3/16/2020 9:43 AM, Andrew Haley via Concurrency-interest wrote:
> > Hi,
> >
> > On 3/16/20 12:11 PM, Ben Evans via Concurrency-interest wrote:
> >
> >> I note that Amazon's Graviton processor is approaching availability
> >> and has some interesting performance and other stats:
> >>
> >> https://www.infoq.com/news/2020/03/Graviton2-benchmarks/
> >>
> >> I was reminded of the oft-repeated idea that Java programmers don't
> >> actually code to the JMM, they code to the stronger x86 hardware
> >> memory model.
> >>
> >> With the arrival of these new processors at an attractive price point
> >> in AWS, are we going to see a wave of previously-dormant concurrency
> >> bugs that are tickled by the difference in hardware memory model?
> > I don't think so, because we've been running a bunch of stuff on
> > AArch64 without many problems. If I had to guess the reasons for that,
> > they'd be
> >
> > 1. Lock-free programming is something of an extreme sport among Java
> > programmers: normal people use synchronized regions and j.u.c
> > structures.
> >
> > 2. Many of the reorderings that processors with relaxed memory
> > ordering do are also allowed to be done by compilers, and Java's C2
> > compiler is quite happy to do them. So even though x86 has a total
> > store order model, the compiler will still mess things up for people
> > who write racy programs.
> >
> >> What can we do to prepare for such bugs, and is there anything clever
> >> we can do to help spot them before they cause issues in production?
> > Ooh, great question! I don't think we have race detectors for Java, but
> > there are severl projects out there.  See also
> > https://openjdk.java.net/jeps/8208520.
> >
> _______________________________________________
> 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