* The zero-argument case requires no traversal of parameter types (e.g. getters and initializers) * when all arguments are untyped, no need to traverse parameter types (includes the zero-arg case) * each of the 10 or so return-type boxing cases can be specialized to avoid switching on the return type None of this requires jit-compilation, but does requires a new indirect pointer in MethodInfo for generic invocation (coerceEnter() and its variants will wrap the indirect call).
OS: Mac OS X → All
Hardware: x86 → All
Target Milestone: --- → Future
Created attachment 413342 [details] [diff] [review] uses template specialization to specialize common sub-cases of coerceUnboxEnter Several things happening here that I'd appreciate feedback on: * some minor encapsulation, no big deal * renaming and refactoring coerceEnter variants (particularly the ones taylored for call and apply). i'm aware that its important for tail-calls to be preserved throughout but i haven't carefully checked that it's happening. * introduces an indirect pointer in MethodInfo for all coerceEnter invocations * finally, introduces 24 specialized variants (8 return types * three cases: zero args, all-untyped args, mixed-typed args). in theory we could also add 1-arg and 2-arg (and so on) variants, but at some point code size matters. more data needed on the distribution of arg-count. Most importantly, I feel like this is a dead end patch except for the wordcode build. in the jit build, creating per-method variants is a bigger win, and when a method is interpreted, having the specialized but non-jit-compiled variant to invoke it, doesn't seem important. so this attachment saves the patch for future work
Assignee: nobody → edwsmith
Attachment #413342 - Flags: review?(stejohns)
Comment on attachment 413342 [details] [diff] [review] uses template specialization to specialize common sub-cases of coerceUnboxEnter some minor nits probably not worth listing here, but on the whole looks sound. agreed that this is probably a dead-end -- not clear if it's worth landing if we're going to produce jitted versions, but definitely worth saving
Attachment #413342 - Flags: review?(stejohns) → review+
Since this change only potentially benefits a pure-interpreter config, I'm changing this to block the wordcode-interpreter tracking bug, instead of the jit-call-overhead tracking bug.
You need to log in before you can comment on or make changes to this bug.