On Mon, Nov 2, 2009 at 12:17 PM, Rémi Forax <[email protected]> wrote: > The idea is to let the code without guard but to be able > to trigger a VM safepoint. At this safepoint, all or some > callsites will be invalided, i.e the callsite target will be flushed > and the callsite will be in state that will require > to call the bootstrap method to re-initialise its target. > > The thread that has triggered the invalidation will hold a lock > to change the hierarchy, i.e do all language specific modifications. > If during this step another thread want to call a callsite target, > because the callsite was invalided it will require to call the > bootstrap method again. And to acheive proper synchronisation, > the BSM should try to take the lock beore installing a new target. > If the lock is held by the thread that has required invalidation, > the thread will just wait on the lock.. > > If invalidation works, you can get ride all of guards against > metaclass modification. And if a metaclass modification > occurs, all callsite targets will be flushed and new target > will need to be reinstalled. > > So please guys, push to have a real invalidation implementation > and don't add guards. Let the VM do the magics :)
This is how JRuby's call site logic used to work, and we'd love to return to that logic. The problem we ran into (and I believe the problem that the DLR guys ran into when they tried the same thing) was that unless you access the inline cache under lock, you can't guarantee that threads won't step on each other. The two can't run concurrently without synchronization since the calling thread might cache a method at the exact moment another thread invalidates, resulting in a stale cache that won't ever be invalidated. It was faster, but we had actual reported bugs from that thread race. If it's possible to have the VM do this for us (correctly), it would certainly be a big help. That is also predicated on invokedynamic being able to do automatically all these optimizations we want to do by hand. For example, invokedynamic doing "fib" against our boxed Fixnum objects needs to be able to reduce it to integer math to be able to compete with the profile-driven "manual" optimizations we would do at a bytecode level. It would be ideal if we could just wire up all invokedynamic call paths and know that those paths will receive all the optimizations we expect from Java dispatches, but I don't know if (or when) that will be the case. (It's not that I don't have high confidence in the VM guys, it's just that I also need a solution for non-indy JVMs :) I'm very much looking forward to indy-based optimizations that would be difficult or impossible for us to do at a bytecode level) - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
