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
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
