529832 - We can specialize several common cases of coerceUnboxEnter

Status: RESOLVED WONTFIX

(Tamarin Graveyard :: Interpreter, defect)

Description

[Edwin Smith]

* 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).

Comment 1

[Edwin Smith]

Attachment: 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

Comment 2

[Steven Johnson]

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

Comment 3

[Edwin Smith]

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.

Comment 4

[Sylvestre Ledru [:Sylvestre]]

Tamarin isn't maintained anymore. WONTFIX remaining bugs.