I assume you're referring to the Dynamic Language Runtime (DLR). DLR does nothing even close to invokedynamic for optimization. The best you can do with DLR is

I assume you're referring to the Dynamic Language Runtime (DLR). DLR does nothing even close to invokedynamic for optimization. The best you can do with DLR is regenerate little dispatch stubs at each dynamic call site, to at least avoid the overhead of re-searching the class hierarchy. These stubs are then reinserted at the dispatch point and used to make the call. Unfortunately, since all current CLR implementations do not optimize code at runtime, these newly-created stubs can't be optimized with the rest of the code. So you get a call from the code to the stub, a few guards, and another dispatch from the stub to the target. Those three pieces never optimize together. invokedynamic is also very useful for optimizing things other than method dispatch. In JRuby master, we're using invokedynamic for constant lookup (as illustrated in this post) and for lazily creating literal values. In both cases, it reduces the access to a single memory hit, much faster than what JRuby 1.6 or any DLR languages can do. tl;dr: DLR is the best you can do for dynamic dispatch optimization at an API level atop current CLR impls and subject to limitations therein. invokedynamic brings true end-to-end dynamic dispatch support to the JVM.