[concurrency-interest] Amazon Graviton and implications for concurrent Java apps
oleksandr.otenko at gmail.com
Wed Mar 18 06:44:30 EDT 2020
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
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.
On Mon, 16 Mar 2020, 16:03 Nathan Reynolds via Concurrency-interest, <
concurrency-interest at cs.oswego.edu> 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.
> 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
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest