On Apr 3, 2008, at 2:20 AM, Charles Oliver Nutter wrote:
> I'm just looking for a definitive answer on why it's better this
> way in
> Java 6.
This particular micro-benchmark happens to be slower in Java 6 than
in Java 5, but if the layouts were changed by four or twelve bytes
the opposite might be true, and we'd have a "win" for Java 6. (If my
previous analysis is correct, which I'm going to assume in the rest
of this note.) Adding an odd number of four-byte static fields
before the two in the micro-benchmark might make Java 5 faster than
Java 6. So this is not a question of quality of implementation that
distinguishes 5 from 6. It is indeterminate behavior that comes from
questionable coding (unsynch. non-volatile static writes).
To me as a VM guy, it's a case of:
P. Doctor, it hurts when I do this.
D. Then don't do that.
The JVM could notice that there is lots of cache ping-ponging on a
pair of separable variables, and reallocate them onto separate
lines. We'll probably eventually do stuff like that, given the new
realities about memory architecture. But at present this is mainly a
research topic that you read about in conference papers.
I agree there are sometimes reasons, especially for language
implementors, to bend the rules, and do things like increment
unlocked counters. (We do it in the JVM all the time, at the C++
level.) But if you are going to bend the rules, you can't expect the
JVM to be ready to know what you mean. You might have to help it
accept the weird code. A good help in this case would be to make
sure the bits of mutable global state are isolated in a corner
somewhere.
Even better (if applicable) would be to have fast thread-local
counters, with a slow background phase which occasionally tallies
them into a trailing global counter. Use compare-and-swap to collect
the fast-moving data into the slow-moving data. This would be faster
and more accurate, at the cost of complexity and extra per-thread
storage. It reflects the reality of non-uniform memory. (This
verges on the old fetch-and-add instruction for massively parallel
machines like the Connection Machine.)
-- John
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en
-~----------~----~----~----~------~----~------~--~---
