river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Next steps after 2.2.1 release
Date Mon, 08 Apr 2013 13:11:02 GMT
On 4/7/2013 7:03 PM, Greg Trasuk wrote:
> I'm honestly and truly not passing judgement on the quality of the code. I 
> honestly don't know if it's good or bad. I have to confess that, given that 
> Jini was written as a top-level project at Sun, sponsored by Bill Joy, when 
> Sun was at the top of its game, and the Jini project team was a "who's-who" of 
> distributed computing pioneers, the idea that it's riddled with concurrency 
> bugs surprises me. But mainly, I'm still trying to answer that question - "How 
> do I know if it's good?" Here's what I'm doing: - I'm attempting to run the 
> tests from "tags/2.2.0" against the "2.2" branch. When I have confidence in 
> the "2.2" branch, I'll publish the results, ask anyone else who's interested 
> to test it, and then call for a release on "2.2.1" - After that, the 
> developers need to reach consensus about how to move forward. Cheers, Greg.

This is an important issue to address.  I know a lot of people here probably 
don't participate on the Concurrency-interest mailing list that has a wide range 
of discussion about the JLS vs the JMM and what the JIT compilers actually do to 
code these days.

The number one issue that you need to understand, is that the optimizer is 
working against you more and more these days if you don't have JMM details 
exactly write.  Statements are being reordered more and more, including actual 
"assignments" which can expose uninitialized data items in "racy" concurrent 
code.  The latest example is the  Thread.setName()/Thread.getName() pair.  They 
are most likely always to be accessed by "other threads", yet there is no 
synchronization on them, including no "visibility" control with volatile even.  
What this means, is that if setName() and getName() are being called in a racy 
environment, the setName, will assign the array that is created to copy the 
characters into, before the arraycopy of the data occurs, potentially exposing 
an uninitialized name to getName().

There are literally hundreds of places in the JDK that still have these kinds of 
races going on, and no one at Oracle, based on how people are acting, appears to 
be responsible for dealing with it. The Jini code, has many many of the same 
issues that just randomly appear in stress cases on "slower" or "faster" 
hardware, depending on the issue.

When you haven't got sharing and visibility covered correctly, the JIT code 
rewrites can make execution order play a big part in conflating what you "see" 
happening verses what the "code" says, to you, should happen.

There are some very simple things to get the JIT out of the picture.  One of 
these, is to actually open the source up in an IDE and declare every field 
final.  If that doesn't work due to 'mutation' of values, change those fields to 
'volatile' so that it will compile again.   Then run your tests and you will now 
greatly diminish reordering and visibility issues so that you can just get to 
the simple "was it set correctly, before it was read" and "did we provide the 
correct atomicity for that update" kinds of questions that will help you 
understand things better when code is misbehaving.

This is the kind of thing that Peter has been working through because the usage 
of the code in real life has not continued in the same way that it did when the 
code was written, and the JMM in JDK5 has literally broken so much software, all 
over the planet, that used to work quite well, because there wasn't a formal 
definition of "happens before".   Now that there is, the compiler optimizations 
are against you if you don't get it right.  The behaviors you will experience, 
because of reorderings that are targeted at all out performance (minimize 
traffic in and out of the CPU through memory subsystems), can create completely 
unexpected results.  Intra-thread semantics are kept correct, but inter-thread 
execution will just seem intangible because stuff will not be happening in the 
order the "code" says it should.

Gregg Wonderly

View raw message