RFR (S): JEP-142: Reduce Cache Contention on Specified Fields (original) (raw)
Martijn Verburg martijnverburg at gmail.com
Thu Nov 22 13:55:31 PST 2012
- Previous message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Next message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Aleksey,
A couple of small questions/comments from an enthusiastic amateur, take with a grain of salt (inline).
So this in theory takes care of the False Sharing problem without resorting to tricks, great!
Note that we use 128 bytes, twice the cache line size on most hardware
to adjust for adjacent sector prefetchers extending the false sharing
collisions to two cache lines.
Is this based on detecting the size of the cache line of the CPU the JVM is running on and multiplying by two?
I can see architectures changing over time (bigger cache lines? Who knows). Also, wouldn't a padding of 64 bytes be fine to avoid prefetchers for a 32 byte cache line based CPU whereas 128 is overkill?
*** IV. Contention groups
There are cases where you want to separate the group of fields that are experiencing contention with everything else but not pairwise. This is the usual thing for some of the code updating two fields at once. While marking both with @Contended would be sufficient, we can optimize the memory footprint by not applying padding between them. In order to demarcate these groups, we have the parameter in the annotation describing the equivalence class for contention group. So that: public static class ContendedTest5 { @Contended("updater1") private Object contendedField1; @Contended("updater1") private Object contendedField2; @Contended("updater2") private Object contendedField3; private Object plainField5; private Object plainField6; } ...is laid out as: TestContended$ContendedTest5: field layout @ 12 --- instance fields start --- @ 12 "plainField5" Ljava.lang.Object; @ 16 "plainField6" Ljava.lang.Object; @148 "contendedField1" Ljava.lang.Object; (contended, group = 12) @152 "contendedField2" Ljava.lang.Object; (contended, group = 12) @284 "contendedField3" Ljava.lang.Object; (contended, group = 15) @416 --- instance fields end --- @416 --- instance ends --- Note contendedField1andcontendedField1 and contendedField1andcontendedField2 are padded from everything else, but still densely packed with each other.
That's a nice addition.
The code is known to work at least on Linux x86-64, tested with a few microtests. The layout of fields without @Contended is not affected, so this is presumably a safe change. I will try to run more tests against this implementation with JPRT, but will appreciate the design, API, and draft implementation review meanwhile...
I've forwarded this to a few folks who actually know what they're talking about and have complained about false sharing for some time, hopefully they'll pop in.
As an extra aside - I'm wondering if the IDE vendors could pick up on this and actually visualise for you how your class will be laid out. Would be useful when applying @Contented and making sure it's padding as you'd want it to.
Cheers, Martijn
- Previous message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Next message: RFR (S): JEP-142: Reduce Cache Contention on Specified Fields
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]