On Apr 29, 2008, at 3:55 PM, Charles Oliver Nutter wrote: > We do not yet support specific-arity calling for compiled Ruby > methods or closures, which will both likely represent additional perf > boosts in the future.
JRuby has gone a fairly long way toward splitting calling sequences into a set of refinements, each of which is closer (than the generic calling sequence) to what the JVM prefers. There's usually some semantic mismatch, such as (e.g.) a maximum number of positional arguments, or a policy of always boxing primitives. I think each language (and its users) will favor some particular sweet spot where the calling sequences are refined to some degree, and the remaining mismatches to the JVM are not felt to be painful. Or, at least, not as painful as the complexity of fixing them. In a word, the JVM prefers to put argument values in registers than in objects. Escape analysis, inlining, and compiler intrinsics (and fixnums, some day) are examples of optimizations which get more values into registers than the bytecodes would seem to allow. But on the JVM it will always be at least a little faster to unbox your argument lists, and unbox your primitive arguments and return values. The reason we are doing method handles the way we are is to cut down the complexity of dealing with a variety of call signatures in a runtime. Probably, most runtimes, like JRuby, fix a handful of manually-defined call types and manually sort them out. It is possible to make factory-based systems also which can spin out an infinity of call types (that's the way my old esh VM worked). But the real simplification of such tasks will come when the JVM can manage hundreds of call signatures without creating hundreds of glue interfaces and classes, and when we build a low-level runtime that makes the management simple. Then it will be possible to contemplate a design where your dynamic language call sites are customized to a good guess as to the outgoing argument types (via profiling or static analysis or both) and will be linked (as in JRuby) through adapters that usually hit straight through, to the target method, whether the target is a tightly typed Java library routine or something looser. If you write foo[0] and foo is usually a list (and 0 is always zero), then the dynamic call site should, after warmup and linking, directly call List.get(int), without extra motion. This can work; I've seen it work in the past. A further, crucial simplification will come when call sites can be linked according to language-specific rules, instead of being statically tied to Java classes or interfaces. This is what invokedynamic is for (beyond method handles). At that point it will be practical to get rid of IMyLanguageInterface and MyLanguageInteger. It's a good time to be a language and VM hacker... -- John P.S. The JSR 292 EDR is forthcoming... See my blog in the meantime. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
