I've been making more and more JRuby paths use invokedynamic, and trying to get more of those to bind straight through with methodhandles (rather than via our intermediate DynamicMethod class). Most numbers are looking great...even some benchmarks against core JRuby methods that are implemented in Java are faster (sometimes much faster) when invoked via indy. Very exciting!
One case that's a lot slower, however, is this red/black tree benchmark: https://github.com/headius/redblack Without indy, it runs in around 2s after warmup. With indy, the best it gets is 8-9s. Probably safe to say it's 3-5x slower. Many call paths in JRuby still are not directly binding and go through DynamicMethod. Those paths do have more overhead than they should, but probably not more than CachingCallSite would introduce. So it seems like there's either a bottleneck in indy itself or I'm doing something wrong on my end. I would test this against mlvm head, but as reported in my other email there's an exception when building catchException handle adapters... - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
