I want to reiterate what Peter is saying with perhaps some different words and experiences. When Java 5 came out, for the first time, JDK/JRE development started focusing on removing “locks”. That is improving scaling, by changing libraries and the runtime environment to not assert “fences” or other cache synchronization any more than necessary, given the “view” of the associated data that those libraries had, and advertised as being “side effects”.
As I’ve discussed here before, one of the most destructive activities that has happened in the JDK, has been the “enforcement” of “volatile” vs “non-volatile” correctness in the activities of the JIT. The standing example, is this: class foo implements Runnable { bool done; public void run() { while(!done) { doAllTheWork(); } } public void stop() { done = true; } } In JDK 1.4 and before, this class would function correctly on single processor machines (which most developers used), and would hardly ever exhibit a “bug” on multi-core and multi-processor machines. In JDK 5 and later, the JIT rewrites this class to look like class foo implements Runnable { bool done; public void run() { if(!done) { while( true ) { doAllTheWork(); } } } public void stop() { done = true; } } This is all because “done” is not declared volatile. Volatile was in the language but had no effect before JDK1.5/5.0 and this kept most people from putting it into their code. If done is declared volatile, then the compiler will not rewrite the loop, because it will then “know” that the value of done can change outside of the loop’s view. There are other places that such “volatile” consideration is happening. The second point is that Vector and Hashtable, used to cause a lot “synchronization” to happen automatically, because their “locks” created “happens before” relationships in code such that cache flushes occurred regularly. This kills performance in a multi-processor environment, and thus we’ve seen Doug Lea and others’ activities that have been removing “as much as possible” behind the scenes cache manipulation and/or fences that would cause internal processor state synchronization across cores. Ultimately, all of this is what Peter has been so dedicated to go after and deal with. Many of you probably don’t have “problems” with your code, that you recognize, because you are being “helped” but the use of some “heavy weight” collection that is “synchronizing” all of your other activities between cores. I would encourage you to think long and hard about “odd behaviors” that you see in your long running Java applications. Do you see certain activities slightly delayed, yet they occur, and near the moment of some other “Collection’s” usage? Are there other things which seem to “wait” longer than you’d expect. These delays are the kinds of things which are a result of “delayed” synchronization created by another object’s interaction with the memory/cache subsystem. It’s amazingly frustrating and has made Java a very complex language to use, because the focus is first on “all out performance” and not on “developer success”. Gregg On Dec 17, 2013, at 8:12 AM, Peter <j...@zeus.net.au> wrote: > Remote objects, when exported are exposed to multiple threads. > > Even when a Remote object only has one client, the clients calls will be > despatched via a thread pool to the exported object, every method call is > likely to be invoked by a different thread. > > If your exported objects aren't thread safe the method despatch threads are > not guaranteed to see each others changes to the mutable state of your > exported object. > > No Jini releases were designed for the new Java Memory Model that accompanied > Java 5, in fact the first release designed for Java 5 was an Apache River > release. > > We have been strangely fortunate in spite of no services in any existing > releases to date being safely constructed, we've experienced few noticable > consequences, other than some random test failures on Jenkins. To continue > using the existing codebase and do nothing would ensure River's extinction. > > The skunk/qa_refactor branch uses safe construction tehniques and export > after construction, it's had sweeping changes made internally to classes to > significantly improve Java Memory Model compliance. > > If you haven't checked out this branch, now's the time to do so. > > Regards, > > Peter.