On 01/24/2014 06:45 PM, Paul Sandoz wrote:
> I think the update to java.lang.invoke.MutableCallSite.java should be safe:
>
> public static void syncAll(MutableCallSite[] sites) {
> if (sites.length == 0) return;
> STORE_BARRIER.lazySet(0);
> - for (int i = 0; i < sites.length; i++) {
> - sites[i].getClass(); // trigger NPE on first null
> + for (MutableCallSite site : sites) {
> + site.getClass(); // trigger NPE on first null
> }
> // FIXME: NYI
> }
>
> However, that got me wondering about that STORE_BARRIER. IIUC it is
> using a static AtomicInteger and a call to lazySet to in effect
> emulate a StoreStore (release) barrier or the equivalent of
> Unsafe.storeFence, so the AtomicInteger could be replaced with
> Unsafe. (When there is an update to the JMM it might be possible to
> update docs on syncAll.)
Thanks for reminding me about this.
The "JMM Details" outlined in Javadoc for MutableCallSite.syncAll() [1]
seem wishful thinking to me. Particularly the part when the notion of SO
totality somehow transforms into visibility for
non-synchronization-action reads. The point about "synchronization-order
consistency" is a moot, because it is only spec-ed for volatile actions.
The visibility guarantees for everything else are provided by HB, which
is not applicable here. That is, spec-wise, without the paired volatile
read of the same AtomicInteger observing the written value, we are not
guaranteed to see the updated MutableCallSite value.
Since JEP 188 tries to also rigorously spec fences, I'll ping Doug to
add this into JEP 188 tally.
-Aleksey.
[1]
http://docs.oracle.com/javase/7/docs/api/java/lang/invoke/MutableCallSite.html#syncAll(java.lang.invoke.MutableCallSite[])
