It was possible to loose a pop_unwind because it was detected as dead code, which meant that handlers weren't being unregistered properly. This caused infinite loops checking handlers. This makes it so that JIT entry to codegen the landing pad of an exception handler causes the handlers list to be pop'd, so it can't reenter itself.
The previous ruby_bug guard is questionably correct. It is more accurate to say that MRI behavior changed than that the previous behavior was a bug that was fixed. The change in #1648 is more an API change than it is something like 1 + 2 == 4. Since all alternative implementations are expected to pass all ruby_bug guarded specs, the ruby_version_is guard also makes more sense, since the different behavior was added in 1.8.8dev.
This does not use the caching scheme previously used because: 1. only .c and .cpp files have dependency entries 2. if a.cpp includes a.hpp which includes b.hpp and b.hpp is modified to include c.hpp, the dependencies for a.cpp need to be recalculated. This scenario is not handled by the caching method because there is no connection between a.cpp and b.hpp except in the list of dependencies that are mapped by the dependency grapher. Since the dependency grapher processes all files and caches the result of parsing each included file, the dependency grapher runs in ~2.5 seconds on a 2.8GHz MBP.
…xes describing bytecode for fast math operators and fast generic methods