Summary

Define a way to specify that one or more fields in an object arelikely to be highly contended across processor cores so that the VMcan arrange for them not to share cache lines with other fields, orother objects, that are likely to be independently accessed.

Description

Memory contention occurs when two memory locations that are in use bytwo different cores end up on the same cache line and at least one ofthe cores is performing writes. For highly contended memory locationsthis can be a serious performance and scalability issue. The aim ofthis enhancement is to avoid memory contention between cores, at leaston fields we can easily identify during development.

The idea is to add padding before and after each field which mightexperience contention to make sure no other field (or other object)can end up on the same cache line. In the general case where no objectalignment is guaranteed, the size of the padding needs to be the samesize as the cache lines of the machine we're running on. If specificobject alignment can be guaranteed, we can then decrease the amount ofpadding needed. For example, if the first field of an object is alwaysguaranteed to be at the start of a cache line, then we only need topad just enough before a field to make sure the field is also at thestart of a cache line, and then pad enough after it to make sure thefollowing field is at the start of the subsequent cache line.

This padding can be implemented reasonably easily at class loadingtime by introducing enough dummy fields to the class. Changing theclass layout afterwards would be much more challenging, especiallyafter instances of that class have been allocated and/or some of itsmethods have been JITed.

If we want to cut down on the memory wasted due to this padding we'llhave to ensure specific object alignment. However, this is a much moreinvolved change that, apart from class loading, will also touchseveral other parts of the JVM: Allocation code (to make sureallocations of specific objects are correctly aligned and also to tagsuch objects as aligned so that the alignment is maintained in thefuture), the JIT compilers (to know which allocations need to bealigned and emit the instructions for the right allocation operation,or call a special runtime method), the GC (to make sure that anyobject that needs to be aligned remains aligned when moved),etc. Given that alignment will probably only allow us to reduce thememory footprint wasted due to the padding, and assuming that mostobjects that need to be padded are not numerous, we might getdiminishing returns by introducing this alignment requirement.

The main challenge is how to allow the developers to specify whichfields might experience contention. One general-purpose way to do thisis to use annotations (although that does require access to the sourcecode). This way the JVM can handle the specified fields in the bestway possible (i.e., by either just padding them, or by a combinationof padding and aligned allocation as discussed earlier).

If it is important to reduce cache contention on objects whose sourcecode is not available (say instances of standard library classes) itcould be possible to provide developers with a special factory methodthat will do the right alignment and padding so that the allocatedobjects to not share cache lines with other objects.

Impact

• Performance/scalability: The goal is to improve performance formultithreaded applications and allow them to scale better. Paddingobjects does imply higher memory usage.