Does MutableCallSite.syncAll actually work?
Brian S O'Neill via Concurrency-interest <[email protected]> Sat, 11 Sep 2021 10:52:16 -0700
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <[email protected]> |
The documentation for the MutableCallSite.syncAll method appears to be
quite thorough, and in particular: "In terms of the Java Memory Model,
this operation performs a synchronization action which is comparable in
effect to the writing of a volatile variable by the current thread, and
an eventual volatile read by every other thread that may access one of
the affected call sites."
https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/lang/invoke/MutableCallSite.html#syncAll(java.lang.invoke.MutableCallSite%5B%5D)
Upon inspection, I see that the implementation is quite trivial and
somewhat old-skool with respect to memory barrier enforcement.
public static void syncAll(MutableCallSite[] sites) {
if (sites.length == 0) return;
STORE_BARRIER.lazySet(0);
for (MutableCallSite site : sites) {
Objects.requireNonNull(site); // trigger NPE on first null
}
// FIXME: NYI
}
private static final AtomicInteger STORE_BARRIER = new AtomicInteger();
Given the FIXME comment, which I assume means, "not yet implemented",
does the syncAll method actually do anything? I don't understand the
low-level details regarding how dynamic call sites get updated within
HotSpot, but perhaps a simple memory barrier is all that's required? If
so, that's great, and then I suppose the FIXME comment is wrong.
Otherwise, this looks like a bug when considering the well specified
documentation.