|
Java and linear scalability
Objects in Java are the basic building blocks of the language. Objects contain data, and sometimes objects point to data contained within other objects. As Java applications become more and more complex, and as more and more lists and arrays hold objects and data, and as more and more lists and arrays hold pieces of data that indirectly point at other pieces of data, keeping track of what is where and who is pointing at what becomes incredibly confusing.
To maintain any semblance of order, concurrent Java programs use threads that lock pieces of data when a part of the program (let's say Method A) needs access. If another part of the program (Method B) needs access to that same piece of data, Method B is locked out and needs to wait for Method A to finish and unlock the data.
The more processors your throw at a Java program, the more often these data collisions happen, and you eventually hit a point where the whole JVM is simply bogged down in the process of managing and manipulating locks. A point eventually gets reached where adding another processor is about as productive as adding another mythical man to the development team.
"Java provides threads and locks as the primary parallel programming model during operation. It is very simple, it is very straight forward, but it has an obvious cost model. It turns out that in practice in large programs, it becomes very difficult to get it right unless you add locks everywhere. The result of this is that your program does not scale because your threads are all competing on locks, often competing when there isn't even an underlying data contention." So said Cliff Click in an earlier discussion on the topic. "JVMs have made huge strides in making locks cheaper and cheaper and cheaper, but ultimately, they cannot make the cost go away." |
|