Jochen Theodorou wrote: > I asked, because I am searching for a way to make the call site cache > less thread sensitive.. for example to be able to get the method while > updating the cache at the same time... I also considered a event > listener system for meta classes in Groovy... a call site cache could > then simply register itself by using a special listener.. of course > multi threading and listener are always a dangerous combination...
There's two ways I've hoped to avoid overcomplicating the threading issues. The first is to always store the contents of a call site as a single immutable unit...a tuple of [type, method]. The first thing the call site does is grab that tuple, perform a type comparison, and probably call the method. That avoids calling a method against the wrong type. It's probably also worth mentioning that JRuby does no type specialization of any kind at the call site, and only specializes arity in cases where it can be determined statically (i.e. we don't do anything special for splatted/spread arguments). On the caching side, after a successful method has been successfully looked up the tuple is constructed and stored. This is where it's a little squirrelly in current JRuby, since there's a chance that another thread will have redefined the cached method between the time we look it up and the time we cache it, resulting in this cache having a stale entry that might never be flushed. As I mentioned before I have not been able to reproduce this experimentally and it would be a strongly discouraged for many other reasons. But it's still a very real possibility. Ultimately, some kind of locking will probably be necessary to support a completely safe active flush. The act of looking up the method, and creating and storing the tuple should be safely synchronized (against something) to prevent relevant cache-flushing changes from happening at that point. In JRuby's case, we also have a threshold after which a call site is considered "failed" and we always follow the slow path from then on. This saves the overhead of constructing and storing the tuple, and would similarly save the overhead of synchronization for cases where we're never going to have a successful cache. I think this is a reasonable minimization of sync at the call site, though I'd still prefer a 100% reliable guard (e.g an O(1) version check) over actively flushing. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
