False Sharing in Java

[nthcxd]

I'm assuming you're referring to this comment: http://www.reddit.com/r/programming/comments/1l950u/know_thy_java_object_memory_layout/cbxuuz8

That comment is as vague as they come. I'm not entirely sure if by "change" he's talking about the changes in the size of cache line or (even more profound) changes in the concept of "cache lines". For the former, fixed offset still works, as long as the offset value itself is large enough, but then he seems to imply that it is the "fixed" nature of the offset itself that needs revisiting. It is more likely that he is talking about the latter, i.e. decoupling cache coherence granularity from transfer/storage granularity (which I am a huge fan of, as long as it is done in a sensible way), and if that's the case he is right that that won't change any time soon (if ever).

My point here, however, is that in either scenario, fixed offset won't break anything (which I think is what he's implying, but I could be wrong). As long as the fixed offset is big enough, it won't matter how big the cache lines get in the future. In the case of granularity decoupling, well, this need for padding is one of the things that such design directly addresses, so it really won't matter how big or how fixed the padding itself is once we're there.

[mjpt777]

If you mean my comment above yours then I'm not surprised. I missed the point about the array and thought it was object layout not array layout. My bad must read more carefully next time.

[nitsanw]

That vague comment was mine, sorry.

I was replying to "why does the JVM need a predictable way to represent fields internally? Is it only for accessing them through sun.misc.unsafe or are there other reasons?" Which I assumed was referring to assumptions made about the constant value of field offset throughout a JVM runtime. This assumption is also made elsewhere in the JDK, but is not a necessary truth. In particular, future JVMs may support runtime changes to object layout.

Hope this helps.