request for advice: safepoints in the JSR 292 spec

[Rémi Forax]

On 12/12/2010 05:02 PM, Rich Hickey wrote:
>
> On Dec 11, 2010, at 6:30 PM, Jim Laskey wrote:
>
>>
>> On 2010-12-11, at 4:38 PM, Rémi Forax wrote:
>>
>>> I think it's possible to use a synchronized block enclosing the 
>>> setTargets and the corresponding syncs
>>> instead of syncTargets. From my experience, changing something on a 
>>> metaclass
>>> often require to propagate changes on subclasses. This can't be done 
>>> using atomics
>>> so you already need such synchronized block.
>>
>> Maybe I misunderstood.  I was assuming that syncTargets was a VM 
>> operation (at safepoint.)
>>
>>
>
> Right.
>
> Rémi's synchronized block only coordinates the activities of updaters. 
> Other threads may, and in some cases may have to, see some of the 
> setTarget results prior to the sync call, which could be a mess. The 
> point of syncTargets is to make the setting and the visibility atomic, 
> which synchronized cannot do.
>
> Rich
>

Rich,
I don't think you can provide an optimized method handle when syncing but
more probably a default generic method that will later installs a fast path.

So if the result of setTarget is visible before the sync call, it will 
execute
a default generic method which will also enter in a synchronized block.
This will effectively coordinate things between readers and writers.

invariant broken (writer):
synchronized(masterLock) {
   // mutate meta data
   // update all callsites
   foreach(impacted callsites) {
     callsite.setTarget(callsite.defaultGenericPath);
   }
   sync(impacted callsites);
}

default generic method (reader):
synchonized(masterLock) {
   // check arguments
   // use meta data to create a fast path
}
setTarget(guard + fastpath);


This pattern intends to mimick the way the VM do lazy deoptimization
i.e mark the callsite as deoptimized and later when the callsite is used
re-create a fast path.

Rémi