That would significantly speed up DOM bindings, by reducing the need for type conversions.
JM is gone
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → INVALID
We might want something like this for IM, though...
(In reply to Boris Zbarsky (:bz) (reading mail, but on paternity leave) from comment #2) > We might want something like this for IM, though... Is this still worth it for DOM calls with the jitinfo stuff etc we have now?
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Summary: Figure out a way to call things sort of like traceable natives for JM, using type inference → Figure out a way to call things sort of like traceable natives for IM, using type inference
That's a good question. The primary benefit of the traceable natives was that they avoided the need for argument and return value boxing/unboxing. The jitinfo stuff does nothing to address this (though it helps with this-value unboxing, and helps speed up return value unboxing a bit by communicating the general kind of return value). It's pretty easy to write testcases in which the boxing and unboxing is a significant fraction of the time; the question is whether these commonly matter in web code... The main likely beneficiary would presumably be WebGL; roc has had some thoughts about it in the past.
Ah, so IIUC, the idea would be to have, hanging off a DOM builtin's jitinfo, an array of argument/return-type-specialized overloads that could be called directly? ISTR, that's what we did for traceable natives.
Or something along those lines, yes.
I thought for each WebIDL method we'd have one function whose signature matches the corresponding C++ method (with 'this' passed as an explicit parameter), which tail-calls the C++ method. Then we could have IM assemble direct calls to this function, under the right conditions (e.g., all parameter types known). Currently I don't know of any benchmarks that definitely need this. The closest I know of is canvas. So let's leave this bug open but not work on it until we have a benchmark.
You need to log in before you can comment on or make changes to this bug.