Bug 201158 – [JSC] JSPromise should work with object-allocation-sinking

• Status: NEW
• Component: JavaScriptCore

[Yusuke Suzuki]

...

[Radar WebKit Bug Importer]

<rdar://problem/54726575>

[Saam Barati]

won't inlining the constructor which will be written in JS now sink the executor function?

[Yusuke Suzuki]

(In reply to Saam Barati from comment #2)
> won't inlining the constructor which will be written in JS now sink the
> executor function?

I would like to sink JSPromise object itself too when it can be done.

[Yusuke Suzuki]

One possible thing (I'm not talking about whether it is possible in our implementation) is, 

Promise.resolve(42).then(function (value) {
    //
});

Promise.resolve's returning promise is essentially unnecessary.

[Saam Barati]

(In reply to Yusuke Suzuki from comment #4)
> One possible thing (I'm not talking about whether it is possible in our
> implementation) is, 
> 
> Promise.resolve(42).then(function (value) {
>     //
> });
> 
> Promise.resolve's returning promise is essentially unnecessary.

Yeah it would be nice too. But is this common?

Maybe through inlining it might become common. That said, don't we need the intermediate promise because "function (value)" isn't called until next run loop tick?

[Yusuke Suzuki]

(In reply to Saam Barati from comment #5)
> (In reply to Yusuke Suzuki from comment #4)
> > One possible thing (I'm not talking about whether it is possible in our
> > implementation) is, 
> > 
> > Promise.resolve(42).then(function (value) {
> >     //
> > });
> > 
> > Promise.resolve's returning promise is essentially unnecessary.
> 
> Yeah it would be nice too. But is this common?
> 
> Maybe through inlining it might become common. That said, don't we need the
> intermediate promise because "function (value)" isn't called until next run
> loop tick?

In the above example, Promise.resolve's promise is unnecessary. It is already resolved. Microtask only contains reactions of Promises, and value for resolution, so Promise object itself is not necessary.