Spread problem with > 10 arguments

[Charles Oliver Nutter]

On Fri, Jul 10, 2009 at 4:24 AM, Fredrik
Öhrström<fredrik.ohrstrom at oracle.com> 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