Just got this in my inbox from the Perl jobs list, which I really ought to cancel my subscription to.
Developer with extensive knowledge of PERL and ability to code 7.5K to10K
lines per day needed at this large financial services company in Stamford,
7-10 thousand lines of Perl per day
!??! Oh, and you have to know VB as well.
Uh… Perl… VB… culture clash?
The initial release of Whirlycache, a high-speed object cache for the Java platform, has been posted on Java.net. We currently believe it to be the fastest object cache in high-concurrency multithreaded environments (but we are willing to revise this claim if someone can demonstrate otherwise!).
During the course of some reading that I am doing for Whirlycache, I started to wonder about the effect that Java’s
volatile modifier really has. So I wrote a test to find out.
Basically, it’s just 32 threads running in a loop of 10 million iterations doing auto-increments on two
long fields, one of which is marked as
volatile. The results consistently look something like this:
Number of loops: 320000000
Non-volatile long: 134162630
Volatile long: 29800659
We can learn two things here: Java’s autoincrement operator is indeed not atomic since it involves a read and a write (but that’s not real news) and
volatile made about 4.5 times more of a difference than I thought it would in this test.
The surprising thing was that the volatile long value was much less than the non-volatile long. I expected the opposite, but it turns out that the fact that each thread has to read the contents of the volatile modifier out of main memory causes each operation’s result to be clobbered by another thread concurrently writing to the same field. When the field isn’t marked as volatile, each thread maintains a local copy of the field in main memory and actually has a chance of doing some work on it before writing a modified copy of the field back into the main memory.
I also found a very good article today on IBM developerworks about Java synchronization.
Over the past few weeks, I’ve been working on some ideas for a Java object cache and now there’s some code to back it up. Seth Fitzsimmons was kind enough to go to the trouble of writing some code and setting up some project space on whirlycache.dev.java.net. That’s where you can monitor our progress.
From what I can tell, Whirlycache is the fastest Java object cache around today. I’d love to know if I am wrong about that.