PJS: Support calling native functions that have parallelized alternatives

RESOLVED FIXED in mozilla25

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: shu, Assigned: shu)

Tracking

unspecified
mozilla25
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
Currently, to call a parallel-safe version of some native function we have to manually inline a callVM inside IonBuilder. This is a pain, and it would be nice to attach a pointer to some parallel-safe version of the native to that native's JSFunction.

I'm eying JSJitInfo as the place to stick this extra pointer, as:
 1) Parallel execution only happens for JITted code.
 2) This is a hint to the JIT for how to compile a call to a native in parallel mode.
(Assignee)

Comment 1

5 years ago
bz, what do you think about my using JSJitInfo for this? I think you're the primary user of that struct currently. Waldo has mentioned plans for that struct to be general purpose for other kinds of hints in the future.
Flags: needinfo?(bzbarsky)

Comment 2

5 years ago
Somewhat more precisely, for JSJitInfo to be part of public API, with whatever info it needs for JIT stuff, or speedups generally.  :-)  Mostly the question is for a sanity check on me thinking it's not an unreasonable place to add stuff.

One minor question: how deeply internal are the bits that'll be exposed this way?  JSJitInfo right now doesn't have anything too internal in it -- just reasonably-explainable numbers, bools, and function pointers not taking anything internal.  Would the new stuff added know about Ion internals like MIR or lowering or whatever, or would the new stuff be akin to what's already there?
I have no problem with adding this sort of thing to the JSJitInfo structs.  My primary thoughts on those structs are:

1)  We may need to evolve them as TI and Ion evolve and the information they need changes.

2)  We can always move towards having a public jitinfo and a friendapi subclass, with a flag on the public thing indicating whether we're really the subclass, if we have to.

For what it's worth, explaining the returnType member is already a bit of a pain, and the protoID/depth thing is black voodoo unless you happen to know about how it integrates with the DOM....
Flags: needinfo?(bzbarsky)

Comment 4

5 years ago
Yup.  You may have to be "this tall" to use the interface, certainly.  But as long as it's not exposing things we're uncomfortable keeping somewhat stable -- like all the JIT guts -- I'm not opposed.  The DOM stuff will doubtless be hard to use, but that's "just" a matter of documentation, that's probably needed to some degree to explain all this stuff to readers of our existing code.  In contrast, exposing something like, say, MIR or LIR, would be a horrible idea, I hope we all agree.  :-)  That latter is the worry I have about adding stuff here.  If we're not adding something super-internal, I'm not too worried about how complex it might be.
(Assignee)

Updated

5 years ago
Duplicate of this bug: 885953
(Assignee)

Comment 6

5 years ago
Created attachment 766205 [details] [diff] [review]
v0
Assignee: general → shu
Attachment #766205 - Flags: review?(kvijayan)
(Assignee)

Updated

5 years ago
Blocks: 881593
Comment on attachment 766205 [details] [diff] [review]
v0

Review of attachment 766205 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.
Attachment #766205 - Flags: review?(kvijayan) → review+
Blocks: 891877

Comment 8

5 years ago
https://hg.mozilla.org/mozilla-central/rev/891760992548
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.