The call site cache we have currently, InlineCachedCallSite, may not be thread-safe. In general, it will not break in any catastrophic way. However it is the case that if two threads attempt to call against the same site at the same time, and they're both calling against the same type, and while they're calling against that type the type is changed by a third thread, and the last thread to win when updating the call site updates it with old information. Or a simpler case that springs to mind: while a thread is in the call site, the type in question changes; because the call site has not yet registered itself with the type it does not get flushed out by the change, and so we end up with a call site caching the old method forever (or until the next rebinding of that name). This may indicate a key flaw in the push logic for changes, requiring either synchronization as part of cache updating or requiring more guards in the call sites themselves (for example, guards to flush the call site if a class serial number has changed since the last cache).