Bug 201737 - API review of a factory method for creating LookupMerger for ActionProvider
API review of a factory method for creating LookupMerger for ActionProvider
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Generic Infrastructure
7.1
All All
: P3 (vote)
: 7.1
Assigned To: Tomas Zezula
issues@projects
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-07 11:58 UTC by Tomas Zezula
Modified: 2011-09-10 14:27 UTC (History)
1 user (show)

See Also:
Issue Type: TASK
:


Attachments
Diff file (13.28 KB, patch)
2011-09-07 12:01 UTC, Tomas Zezula
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Zezula 2011-09-07 11:58:35 UTC
Added LookupProviderSupport.createActionProviderMerger factory method to create a LookupMerger for merging multiple instances of ActionProvide in the project's Lookup.
Comment 1 Tomas Zezula 2011-09-07 12:01:46 UTC
Created attachment 110469 [details]
Diff file
Comment 2 Jesse Glick 2011-09-07 14:06:43 UTC
[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.
Comment 3 Tomas Zezula 2011-09-07 14:49:45 UTC
JG01: Fixed

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[0] is OK as the JVM does volatile read of array reference (RB) and then read of non volatile element reference.

arr[0] = 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.
Comment 4 Tomas Zezula 2011-09-08 17:28:53 UTC
I will integrate it tomorrow.
Comment 5 Tomas Zezula 2011-09-09 08:20:15 UTC
Fixed jet-main c4b75dd33577
Comment 6 Quality Engineering 2011-09-10 14:27:00 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/c4b75dd33577
User: Tomas Zezula <tzezula@netbeans.org>
Log: #201737:API review of a factory method for creating LookupMerger for ActionProvider


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo