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.

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.

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

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.

Comment on attachment 766205 [details] [diff] [review] v0 Review of attachment 766205 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.