request for advice: safepoints in the JSR 292 spec

[Rich Hickey]

On Dec 10, 2010, at 9:04 PM, John Rose 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/9c9d3e84fc745676#
>>>
>>
>> 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/memory/universe.cpp 
>  )
>
> 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