If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

consider exposing a "return value ignored" signal to c++ bindings

NEW
Unassigned

Status

()

Core
JavaScript Engine
3 years ago
a year ago

People

(Reporter: bkelly, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
One of the ways we could optimize our native promises is to avoid creating a Promise in .then() when the return value is ignored.  In order to do this, though, the Promise c++ could would need some way to know the return value does not matter.

Is it possible to expose a "return value ignored" signal to c++ bindings in some way?

If so, then each C++ binding could implement this optimization where it makes sense.
In particular, what might work here is, in the situation where we could DCE the call based on its return value not being used but don't because it's effectful, to flag the MCall in some way... and then somehow make that state queryable from inside the call.
We currently special-case array.splice calls with unused return value in Ion (see array_splice_impl's returnValueIsUsed argument); something like that could work.

Maybe LCallDOMNative can pass an extra word (with a "return value unused" bit) to the DOM method? Passing an extra argument is not free, but maybe there are other things we can put in there or maybe we can combine it with one of the existing arguments.
Hmm.  So array.splice uses BytecodeIsPopped(pc).  Does that mean we know statically, based on the pc, that the return value is unused, and don't have to rely on the JIT to do the analysis?

Past that, we could do the extra arg thing, yeah.  We'd make it opt-in on the part of the DOM method (as in, you'll need an IDL annotation to indicate you want the extra arg), so it won't slow down things that don't care about the optimization.  Combining with one of the existing args is pretty hard, sadly, though I'll think about it some more.
(In reply to Not doing reviews right now from comment #3)
> Hmm.  So array.splice uses BytecodeIsPopped(pc).  Does that mean we know
> statically, based on the pc, that the return value is unused, and don't have
> to rely on the JIT to do the analysis?

Yup. Doing this elsewhere in the JIT might catch a few more cases, but it's probably also a bit more complicated.
You need to log in before you can comment on or make changes to this bug.