Added LookupProviderSupport.createActionProviderMerger factory method to create a LookupMerger for merging multiple instances of ActionProvide in the project's Lookup.
Created attachment 110469 [details]
[JG01] Javadoc should be clarified: the first AP which supports the command _and is enabled on it_ will perform it.
[JG02] I think the VolatileArrayField warning (whatever that came from) is probably correct - writing and reading a complex type like an array or structured object without any synchronization could in principle lead to one thread seeing a partially written result. Making the field volatile merely discourages a compiler from optimizing accesses to it, but does not introduce a memory barrier that I know of.
JG02: No. In the JSR 133 (JDK 1.5) volatile read/write was fixed. Before JSR 133 it was allowed for volatile writes to be reordered with nonvolatile reads and writes. But this was fixed by JSR 133. In JSR 133 volatile write ensures visibility of all writes which happened before the volatile write (they cannot be reordered with non volatile writes). The volatile read cannot be reordered with nonvolatile reads. The non volatile write happened before volatile write which happened before volatile read (of the same field) which happened before non volatile read. So there is ordering of the operations. The volatile according to JSK 133 can be seen as half synchronized. The volatile read is RB and volatile write is WB.
Here is how JIT can do reordering according to JSR 133.
1st operation 2nd operation Reordering Allowed
Normal Load/Store Normal Load/Store Yes
Normal Load/Store Volatile Load Yes
Normal Load/Store Volatile Store No
Volatile Load Normal Load/Store No
Volatile Load Volatile Load No
Volatile Load Volatile Store No
Volatile Store Normal Load/Store Yes
Volatile Store Volatile Load No
Volatile Store Volatile Store No
Now comes the tricky part (arrays). Suppose:
volatile String arr;
which means arr reference is volatile but it does not mean that reference to arr elements is also volatile.
So reading the arr elements:
a = arr is OK as the JVM does volatile read of array reference (RB) and then read of non volatile element reference.
arr = a is NOT OK as it's RB not WB. The JVM read volatile reference of arr (RB) and then does non volatile write of the element.
But in the diff there is no modification of the array after volatile write, so it's OK and warning makes no sense.
I will integrate it tomorrow.
Fixed jet-main c4b75dd33577
Integrated into 'main-golden'
User: Tomas Zezula <email@example.com>
Log: #201737:API review of a factory method for creating LookupMerger for ActionProvider