On Dec 10, 9:04 pm, John Rose <[email protected]> wrote: > On Dec 10, 2010, at 5:08 AM, Doug Lea wrote: > > > On 12/09/10 19:09, John Rose wrote: > >> I started a thread on Google Groups to get more advice on safepoint-based > >> invalidation, which the EG is naming MutableCallSite#sync. > > >>http://groups.google.com/group/jvm-languages/browse_thread/thread/9c9... > > > TL;DR version: The scheme you laid out here seems sound. > > Thanks very much, Doug. I assume you are primarily referring to part (a) of > my question: > > >> In order to work, the specification has to (a) make logical sense in the > >> terms of the JMM, (b) be reasonably implementable by JVMs, and (c) be > >> useful to programmers. > > Does anyone have a take on (c)? (See my comments below on using this API...) > > > In the JSR 292 case, we are supporting languages (like Java!) which can > dynamically change their type schemas, but do so infrequently, perhaps at > phase changes. The changes will in general require complex sets of call > sites to be updated, implying a dependency mechanism (see the Switcher class > for this). But the actual change-over can be slow, and may involve > safepoints, as today with devirtualization that happens when new classes are > loaded. > > (See Universe::flush_dependents_on around line 1100 of: > http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/tip/src/share/vm/me...) > > The idea is that the type schema change would be prepared (as a "next global > state") by a writer thread #1. At this point some call sites become "invalid > in next state". Those call sites would be switched, either by a switcher > (which would in general control many call sites at once) or by editing them > individually, and then calling 'sync' on them. > > The new state of all call sites must at this point be consistent with both > the current and next global state of the type schema. Typically, a lock > would be held on the schema by writer thread #1, and the updated call site > paths (now switched in and sync-ed) would pile up on the schema lock. After > the next global state is installed as current, the writer thread #1 lets go > of the lock, and callers are free to shake out the new state of affairs. > > The shake-out may include installing optimized call paths in various call > sites. This means that a mutable call site might undergo two mutations, the > first to get into a state consistent with both old and new schemas (perhaps > seizing a lock, as above) and the second to optimize calling within the new > state. Both transitions generally need to grab a lock so they can have a > consistent view of the global schema state. > > As an extra complication, the editing of call sites is probably performed in > a concurrent manner, and lazily. There might be writer thread #2, etc., > performing updates to mutable call sites. It it not clear to me whether the > second write also needs a sync, but it looks like that may be the case to get > performance. Perhaps the right way to go is avoid the second write, and have > the first write install the optimized path immediately, and queuing a 'sync' > request to be executed after a short delay. One key concern is to avoid > "safepoint storms", by batching 'sync' requests. > > -- John
Thanks for this work, John! I'm concerned about the separation of update and publication in this API. It seems intractably difficult to reason about the behavior of the system between multiple setTarget() calls and a subsequent sync(). I'd much rather see (if possible): public static void syncTargets(MutableCallSite[] sites, MethodHandle[] newTargets) Then we can create arbitrary composite updates, out of view and over time, using mere-mortals programming, and deliver them atomically. Ditto Switchers (if they would even still be needed). And I wonder about VolatileCallSite. Who would ever use that, given MutableCallSite? Perhaps setTarget() should simply go away? Regards, Rich -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
