In #8748 I made some quick changes to reduce the impact of invokedynamic on class hierarchy invalidation, cutting the overhead of Kernel changes by around 5x. However there remains additional overhead throughout our use of invokedynamic that should be addressed:

• Method handles being repeatedly acquired and adapted, especially painful during early boot stages when every call site is getting invalidated.
• Cost of adaptations and Binder/SmartBinder API use.
• Wasteful overhead and exceptions when trying additional overload signatured for direct arity binding.
• Cost of LambdaForm and unoptimized MethodHandle chains when first used.
• Remaining overhead of invalidating down-hierarchy for every method table change.

A number of techniques would aid us here:

• Cache more method handles as appropriate, including for multiple overrides and different call site adaptations. Ideally a given method should only generate a new handle for a given call+target shape once, not repeatedly as for some current cases (overload searches, Java dispatch).
• Flip hierarchy invalidation to call sites. If each call site aggregated the SwitchPoint instances from all parent classes, we can invalidate by individual class rather than against the whole subhierarchy. This will add some cold execution overhead to call sites, but greatly reduce the cost of high-hierarchy invalidations (e.g. at boot time).
• More Intelligent caching of Binder/SmartBinder forms that are used repeatedly. Both APIs produce immutable objects, so they are safe to cache as long as they do not contain site or call-specific bound objects.

With JRuby 10 enabling indy by default, this is a priority and should go into an early 10 patch release.