On Fri, Jul 10, 2009 at 4:24 AM, Fredrik Öhrström<[email protected]> wrote: > I would like to throw out an open question: > > For dynamic languages like Ruby, that do not have > typed primitives and can work with arbitrarily large > numbers, when will the transform happen where these numbers > are translated from number-objects into ints when used > as method arguments? > > If this can happen at static compile time of the Ruby > program into bytecodes. Then you have a weird situation > where you are able to deduce that both the caller > and the destination will never exceed the int-capacity, > but you will not know the actual destination! Since > if you did, at static compile time, you would be > able to use a normal call instead. > > On the other hand, if this can only happen during > runtime, then for a small interpreting-only JVM, > you will have to take into account that the Ruby > optimizer will be interpreted! What will the > cost/benefit analysis be for this? It seems > unlikely to me that it would make sense to > over-optimize in such an environment. Better > to work with number-objects and get almost > zero cost at the transforms using generic > invocation.
There may be limited cases where we can turn boxed math into integer math, but it's going to be rare (if even possible) to do it easily across method call boundaries. Since Ruby has no type hints (yet...I'm considering them for JRuby), the best we'd be able to do would be to have smart enough compilers to propagate "fixnumness" as widely as possible, based on literals, type-profiled call sites during ruby interpretation, and possibly type-profiled method arguments. Given that information it's possible we could start to propagate ints more widely by producing a couple different bodies of code, but then we're running off into the weeds...we already run into issues with the amount of code we generate. For the foreseeable future, without type hints, I think we're almost certain to stick with number objects across all call boundaries, and only limited int-type propagation within a method body. - Charlie _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
