This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Are there common JVM switches, special JVM or whatever to provoke memory barrier issues, I have a hard time convincing some programmers that such things really exist particualrly if they work on one CPU boxes. What I'ed like is to throw a switch on the JVM so that it would do its best to provoke one i.e. each thread do its umost to keep a cached copy of all write\reads until memory barriers where hit i.e. still obey the JVM spec but be a badly behaved JVM obviously this would make for a very inefficient JVM for running real code but I think it would be useful from a testing point of view.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
[Henry]: The JVM specification also specifies memory accesses somewhat -- and I believe, to have many threads see many different values for multiple references, because they are cached, violate that.
I think it's only a violation if there's no synchronization, and the variable in question was not declared volatile. Oh, and there are special provsions for final instance fields, to ensure that their values are correctly observed by other threads after the constructor completes. But for non-synchronized, non-volatile, non-final stuff, all sorts of strange behavior is still possible.
[Henry]: Regardless, I don't know what "badly behaved JVM" means. Either you pass the JCK, and is a certified JVM, or not.
I would guess that in this context, it means a JVM which exhibits the most counter-intuitive behavior that is allowed. E.g. a thread caching a local copy of a non-final field, and not bothering to ever refresh it unless forced to by synchronization or volatility. In reality problems with insufficient synchronization are often difficult to detect because refreshing does occur fairly often - but it's not required. I like the idea of a command line flag to maximize "bad behavior" (within the bounds of what's legal behavior) in order to make bugs more detectable. However I haven't heard of any such thing actually being implemented.
Perhaps 'Badly behaved' was a bad choice of phrase but I was after a JVM as Jim described purely for testing purposes.
I've always assumed that such problems would be hard to produce on single CPU PC's but would increase proportional to the number of CPU's a machine has, which as we see a rush to multicore / CPU machines would result in a lot of older code failing ?? I do appreciate that this isn't necessarily true i.e. I'm making some big assumptions as to how threads are implemented under the hood (accahing etc) not required by any JVM spec (JCK) i.e. certainly wouldn't be true of the single threaded JVM Oracle implements native to its database for instance I believe ;-)
I do find it strange some companies stressing large scale JUnit automated testing but wouldn't think to test purposely there multithreaded code on multiple CPU based machines and it would be nice to have a JVM as described to provoke some otherwise very rare hard to find bugs, presumably some such bugs might appear very rarely and/or only on specific JVM implementations / hardware however with a JVM as described we could force them to appear every time (ok not on that Oracle JVM) which would be a boon for testing ??