On Wed, May 26, 2010 at 6:45 AM, Attila Szegedi <[email protected]> wrote: > Emphasis is on "incremental" and "deoptimizing" - you can do > type-specializing compilers without JSR-292 if you want today. However, the > ability to swap a dynamic language interpreter with a type-specialized > bytecode with a call site granularity, and the ability to switch back to > interpreter at, again, a call site granularity, are things you need JSR-292 > for.
That's certainly true. Specializing any call path in current JRuby means specializing it for *all* possible targets, and that's cumbersome. That's why we currently only arity-specialize up to three arguments and have no specialized call paths for primitives. Indy certainly makes that easier, at least for arguments. Return values are still a problem, however: for example, when doing Fixnum + Fixnum we may be able to just return Fixnum, and therefore reduce the entire operation to primitives...or we may need to return Bignum if it overflows. That requires a hard bailout to the Object version of a compiled+optimized method. Floats are relatively easy, since they don't overflow into an arbitrary-precision type; if we can show that a given method's calls are all on Float and Float has not been modified...it can be primitive math. I could implement that in a very short amount of time even without indy. - Charlie -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
