Figure out a way to call things sort of like traceable natives for IM, using type inference

REOPENED
Unassigned

Status

()

REOPENED
8 years ago
4 years ago

People

(Reporter: bzbarsky, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Mac OS X
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

That would significantly speed up DOM bindings, by reducing the need for type conversions.

Updated

8 years ago
Blocks: 619423
Priority: -- → P1
Blocks: 683631
Priority: P1 → --
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.

Comment 5

5 years ago
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.
(Assignee)

Updated

4 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.