By Alvin Alexander. Last updated: August 25, 2014
A mailing list discussion about JVM startup time issues, particularly as they relate to JRuby. Part of the discussion:
* Invokedynamic We love indy. We love it more than just about anyone. But we have again had to make indy support OFF by default in JRuby 1.7.14 and may have to do the same for JRuby 9000. Originally, we had indy off because of the NCDFE bugs in the old implementation. LambdaForms have fixed all that, and with JIT improvements in the past year they generally (eventually) reach the same steady-state performance. Unfortunately, LambdaForms have an enormous startup-time cost. I believe there's two reasons for this: 1. Method handle chains can now result in dozens of lambda forms, making the initial bootstrapping cost much higher. Multiply this by thousands of call sites, all getting hit for the first time. Multiply that by PIC depth. And then remember that many boot-time operations will blow out those caches, so you'll start over repeatedly. Some of this can be mitigated in JRuby, but much of it cannot. 2. Lambda forms are too slow to execute and take too long to optimize down to native code. Lambda forms work sorta like the tiered compiler. They'll be interpreted for a while, then they'll become JVM bytecode for a while, which interprets for a while, then the tiered compiler's first phase will pick it up.... There's no way to "commit" a lambda form you know you're going to be hitting hard, so it takes FOREVER to get from a newly-bootstrapped call site to the 5 assembly instructions that *actually* need to run. I do want to emphasize that for us, LambdaForms usually do get to the same peak performance we saw with the old implementation. It's just taking way, way too long to get there.
