VarHandles & LMAX Disruptor

[Aleksey Shipilev]

On 08/18/2015 09:44 AM, John Rose wrote:
> 
>> On Aug 7, 2015, at 1:55 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>>>
>>> Therefore even I use separate field to store the indexMask (entries.length
>>> - 1) to avoid false sharing, the bounds check will effectively undo that
>>> effort?
>>
>>
>> Yes, anything that touches array.length can induce false sharing -- I
>> mentioned this earlier in this thread :) :
> 
> I don't see that this particular case is a big problem.
> 
> If the workload consists of padded arrays, and if the first several
> elements of each padded array A are left idle, then the array header
> (including the field A.length) will be shared read-only.
> 
> The main risk is that an unrelated object X will be allocated *before*
> the array header, and a field X.F toward the end of X will be mutable,
> and will therefore cause conflicts with reads of A.length.
> 
> This risk is lessened because A is allocated with a certain amount
> of alignment.  We could reduce it more if we added a rule (which we
> don't have now) of aligning longer arrays more strongly.  There are
> other reasons to do this as well, having to do with vector processing.
> 
> Anybody want to prototype some stronger array alignment logic?
> It's tricky, but mostly straightforward, except for the extra checks on object
> reallocation in the GC promotion logic.

I am very doubtful about this endeavor. There is a recurrent dilemma:
should one pay for a reduced false sharing with a memory footprint hit?
False sharing evasion is a very special corner case, and so @Contended
pushes that question to users:

"* The effects of this annotation will nearly
 * always add significant space overhead to objects. The use of
 * {@code @Contended} is warranted only when the performance impact of
 * this time/space tradeoff is intrinsically worthwhile; for example,
 * in concurrent contexts in which each instance of the annotated
 * class is often accessed by a different thread.

For the example of arrays, whatever "enable threshold" is, it would
waste anything within [0; 2*cacheLine-2] bytes per array, for *all*
arrays over the threshold. You will never guess the threshold right for
all the usages, and most usages would pay footprint premium for nothing.

In other words, you can't win with heuristics. Therefore, there should
be an alignment hint that could indicate such an alignment constraint
for selected arrays/objects -- something for Panama to work out?

I further think that any band-aid before alignment hints are introduced
only distracts us from making the actual solution. Meanwhile, it seems
that globally optimal strategy is to "just" suck up the bounds check
costs, while waiting for the alignment hints.

Thanks,
-Aleksey