RFR (S): JEP-142: Reduce Cache Contention on Specified Fields

Aleksey Shipilev aleksey.shipilev at oracle.com
Thu Nov 22 13:33:40 PST 2012


Hi,

After some internal discussions with Doug Lea, Dave Dice and others, I
would like to solicit the initial feedback on the implementation of
JEP-142, aka @Contended [1]:
  http://openjdk.java.net/jeps/142

The webrev for the initial version is here:
  http://shipilev.net/pub/jdk/hotspot/contended/webrev-2/

Implementation overview. Hotspot code is currently laying out the fields
to optimize the memory footprint, rearranging fields freely to both
satisfy alignment requirements for fields and making the less gaps
possible. We leverage the same infrastructure to exempt specific fields
from the packing, and pushing them outside the dense packed block at
sparse offsets, naturally making up the appropriate padding.

In order to demarcate the specific classes and/or fields eligible for
such the padding, we use new @Contended annotation. Runtime discovery of
annotations reuses the code John (?) laid out for some of
JSR292-specific annotations.

The behavior of this annotation is as follows:

A. Marking the class as contended:

    @Contended
    public static class ContendedTest2 {
        private Object plainField1;
        private Object plainField2;
        private Object plainField3;
        private Object plainField4;
    }

...makes the entire field block to be padded from the both sides:
(below is the output of new tracing -XX:+PrintFieldLayout)

  TestContended$ContendedTest2: field layout
    Entire class is marked contended
     @140 --- instance fields start ---
     @140 "plainField1" Ljava.lang.Object;
     @144 "plainField2" Ljava.lang.Object;
     @148 "plainField3" Ljava.lang.Object;
     @152 "plainField4" Ljava.lang.Object;
     @288 --- instance fields end ---
     @288 --- instance ends ---

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.

B. Marking the field as contended:

    public static class ContendedTest1 {
        @Contended
        private Object contendedField1;
        private Object plainField1;
        private Object plainField2;
        private Object plainField3;
        private Object plainField4;
    }

...pushes the field out of dense block and effectively applies padding:

   TestContended$ContendedTest1: field layout
     @ 12 --- instance fields start ---
     @ 12 "plainField1" Ljava.lang.Object;
     @ 16 "plainField2" Ljava.lang.Object;
     @ 20 "plainField3" Ljava.lang.Object;
     @ 24 "plainField4" Ljava.lang.Object;
     @156 "contendedField1" Ljava.lang.Object; (contended, group = 0)
     @288 --- instance fields end ---
     @288 --- instance ends ---

C. Marking multiple fields makes each field padded:

    public static class ContendedTest4 {
        @Contended
        private Object contendedField1;

        @Contended
        private Object contendedField2;

        private Object plainField3;
        private Object plainField4;
    }

...pushes both fields with individual padding for each:

   TestContended$ContendedTest4: field layout
     @ 12 --- instance fields start ---
     @ 12 "plainField3" Ljava.lang.Object;
     @ 16 "plainField4" Ljava.lang.Object;
     @148 "contendedField1" Ljava.lang.Object; (contended, group = 0)
     @280 "contendedField2" Ljava.lang.Object; (contended, group = 0)
     @416 --- instance fields end ---
     @416 --- instance ends ---

*** 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 $contendedField1 and $contendedField2 are padded from everything
else, but still densely packed with each other.

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...

Thanks,
Aleksey.


More information about the hotspot-dev mailing list