HN Explorer

7 comments

[ 2.9 ms ] story [ 26.5 ms ] thread
takno
This really needs 2007 attached. Things have changed a lot in the last 9 years
dang
At your service.
stygiansonic
Do you have a link to or example of (major) changes that have happened since 2007? I understand that JSR-133/Java 5 updated/fixed the JMM considerably but was not aware of big changes since then. Thanks.
takno
To be honest I was thinking 2007 predated Java 5. It's been a busy old decade...
happyslobro
And yet, we still have to tell the JVM how much memory it may use, and then watch as it consumes it all, regardless of what the program actually needed. I'm sure there must be reasonable sounding reasons for this, but I doubt they will explain why this was necessary only in Java, and not in any other cross platform VM (V8, compiled Python, etc)
badlogic
What you describe has nothing to do with the Java Memory Model, but with GC tuning, which is an implementation detail. The JMM governs multi-threaded shared memory access semantics. C++11 also defines a MM, inspired by the JMM. V8 and Python are a long way from anything resembling an MM.
avz
The section with the "ugly" examples demonstrates some unintended consequences of the memory model. In particular it demonstrates a counterexample to the first theorem of the original JMM paper [1] which sought to establish that independent statements can be reordered without changing program behavior under the memory model. This got me worried since the theorem provides justification for some of the optimizations actually employed by the JVM.

I dug a bit deeper and found a pending JEP that calls for the update to the JMM to fix these issues: JPE-188 [2]. This links directly to the "Good, Bad and Ugly" paper.

I also found a presentation from one of the authors of "Good, Bad and Ugly" that may make some of this more accessible: [3].

[1] http://rsim.cs.uiuc.edu/Pubs/popl05.pdf

[2] http://openjdk.java.net/jeps/188

[3] http://pan.vmars.tuwien.ac.at/jtres2009/slides/jmm2.pdf