

Know Thy Java Object Memory Layout - javinpaul
http://psy-lob-saw.blogspot.sg/2013/05/know-thy-java-object-memory-layout.html

======
benjamincburns
Does this ordering happen by the JVM at runtime, or is it part of compilation?
Is there a static analysis heuristic which could detect false sharing? Maybe
his could be better solved in the compiler than with implementation-specific
hacks like these?

~~~
tsewlliw
It cannot be done as part of compilation. For example, the superclass you run
against may not be the same as the superclass you compile against.

------
kasey_junk
Thank you! You just saved me another day trying to track down why some
"supposed" hot fields were causing cache misses.

At some point it would be great if Java added some support for memory "hints"
that would allow the JVM to interpret these hacks for what they are.

~~~
fmstephe
I agree.

Maybe not news to you, but I think that there are a few things on the cards
for dealing with memory layout. I know there is a strong push from certain
corners, including Doug Lea, for (object) headerless struct values to be
included in Java 9.

There is a hint of a an @Contended annotation to get the JVM to put a variable
on its own cache line.

But it seems to me that a very effective fix would simply be to ask all JVMs
to stop fiddling the variable ordering.

~~~
lmm
>But it seems to me that a very effective fix would simply be to ask all JVMs
to stop fiddling the variable ordering.

That would make the common case much worse. 99% of Java programmers _want_ the
JVM to optimize their field ordering for them, to the best of its abilities,
so that they can put them in the order that makes sense in the source code and
simply not think about whether a different order would be better. It's the
kind of low-level implementation detail that Java is all about ignoring; if
you want C++, you know where to find it.

I support an annotation-hinting approach; that would keep the common case the
way it is today, while allowing people who really want to fiddle with these
things to do so.

~~~
fmstephe
I would expect that any advantage the JVM gains from variable order fiddling
(and variable dropping) is minimal. Whereas the problems we get on multicore
systems with false sharing, and other cache-line maladies, are significant.

This is, however, just what I expect to be the case. It may be that in
practice the JVM is getting good results from fiddling with our variables.

You may be right that annotations would suit Java better than allowing
programmers to layout objects as they wish. The strong motivation for this is
that the fix would be simple (and perhaps have no serious downside?) and mean
that work can be done without waiting for a JSR to reach maturity.

From what I read the state of the art around this is to use relatively
unstable hacks which require very strong knowledge of JVM implementations -
see the example code from Martin Thomson in the linked article.

You could still happily write your variables for humans in most cases. I would
love to know how large the downside is to fixed variable ordering.

------
RyanZAG
Isn't there a decent amount of overhead in declaring and extending an abstract
class? Does the cache grouping outweigh the overhead?

~~~
kasey_junk
A) It depends on the JVM and B) on HotSpot at least, I believe that it is
smart enough to figure out that all virtual methods are of the same type and
optimize them as if they were non virtual.

~~~
fmstephe
I can confirm that HotSpot is very aggressive at collapsing type hierachies
and de-virtualising method calls.

[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.2420&rep=rep1&type=pdf)

This is one of the places where Java can outperform C++. Where c++ is unable
to statically devirtualise method calls and HotSpot will just do it.

