This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes JVM to provoke mem barrier issues Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "JVM to provoke mem barrier issues" Watch "JVM to provoke mem barrier issues" New topic
Author

JVM to provoke mem barrier issues

Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 407
    
    1

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 Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18509
    
  40

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.

Regardless, I don't know what "badly behaved JVM" means. Either you pass the JCK, and is a certified JVM, or not.

Henry


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[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.


"I'm not back." - Bill Harding, Twister
Chris Hurst
Ranch Hand

Joined: Oct 26, 2003
Posts: 407
    
    1

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 ??
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JVM to provoke mem barrier issues
 
Similar Threads
Advanced Java Memory Model question
address space?
At what point of time volatile variable are wriitten to main memory?
Memory Semantics - Threads
volatile on Windows