Am 20.08.2011 08:14, schrieb John Rose:
> On Aug 19, 2011, at 9:15 PM, Mark Roos wrote:
>
>> The end fallback/lookup is synchronized and so there is only one update at a
>> time, but the
>> new GWT is added to the start of the chain and the second thread is past
>> that point. So
>> when the second gets to the fallback it still thinks the class is missing so
>> it adds it again.
>>
>> The issue would be that the entry to the target is not synchronized.
>>
>> Does this make sense?
> Although the GWT chain is opaque you can store a summary of what's in it on
> the MCS, in subclass field(s).
>
> The update might look something like this:
>
> class MyMCS extends MutableCallSite { ...
> List<Class> casesHandled;
> synchronized MethodHandle ensureCaseIsHandled(Class recv) {
> if (casesHandled.contains(recv)) return;
> setTarget(addCaseToChain(getTarget(), recv));
> casesHandled.add(recv);
> return getTarget();
> }
> Object handleMethodNotFound(Object... args) throws Throwable {
> return
> ensureCaseIsHandled(args[0].getClass()).invokeWithArguments(args);
> }
> }
If you expect to get much less situations where you need to change the
chain, then you may use the double check ideom here.
class MyMCS extends MutableCallSite { ...
MethodHandle ensureCaseIsHandled(Class recv) {
MethodHandle toReturn = analyseChain(recv);
if (toReturn != null) return toReturn;
else {
syschronized(this) {
toReturn = analyseChain(recv)
if (toReturn != null) return toReturn;
return updateChainToHandleCase(recv);
}
}
}
}
Of cause you can use the "shadow data structure" like
List<Class> casesHandled;
as John suggested if this speed up your chain-analyses.
-- Sebastian
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
