Too much for teh twitterz :)
JVM + invokedynamic is in a completely different class than CLR + DLR, for the same reasons that JVM is in a different class than CLR to begin with.
CLR can only do its optimization up-front, before executing code. This is a large part of the reason why C# is designed the way it is: methods are non-virtual by default so they can be statically inlined, types can be specified as value-based so their allocation can be elided, and so on. But even with those language features CLR simply cannot optimize code to the level of a good, warmed-up JVM.
The JVM, on the other hand, optimizes and reoptimizes code while it runs. Regardless of whether methods are virtual/interface-dispatched, whether objects are transient, whether exception-handling is used heavily...the JVM sees through the surface and optimizes code appropriate for how it actually runs. This gives it optimization opportunities that CLR will never have without adding a comparable profiling JIT.
So how does this affect dynamic languages? In several crucial ways.
The CLR's DLR (Dynamic Language Runtime) does optimize dynamic calls by generating code at runtime. This code builds up something like a PIC (polymorphic inline cache) to dispatch to the appropriate target method as quickly as possible. Unfortunately, because the CLR can only do optimization passes ahead of time, before execution, the optimizations in those PICs only apply to the PIC itself; they do not inline to the dynamic call site, and therefore no dynamic calls ever inline. With this comes the loss of the vast majority of optimizations that require inlining, and you end up with better-than-reflection but far-worse-than-inlined performance for dynamic languages.
On the JVM, the story is completely different. Invokedynamic allows the actual in-code call site to be rebound to a chain of "method handles" that eventually lead to the appropriate target method. These handles can implement a direct call, a guarded call, or many complicated patterns of dispatching and inline caching. All that's required is that the logic of making a call be representable as a series of method handles, and the JVM can optimize the original call site as if that logic existed there from the beginning. Further, rebinding call sites at runtime causes the JVM to reoptimize the same code, reevaluating profiles and regenerating native code to match the new "shape" of the site.
None of what invokedynamic does is possible on current CLR implementations, since you obviously can't optimize a late-bound language unless you can delay optimization until runtime.
💣