The funny part is that they _used_ to be completely in C++ (as part of Gecko, not SpiderMonkey). Then they were rewritten to be part of SpiderMonkey, and various bits were made self-hosted in the process. This turned out to be slower than doing it all in C++, for various reasons, some of which might be Gecko-specific (e.g. support for security wrappers).
But in general, optimizing promises as specified in ES6 is _really_ hard. There's all sorts of work that the spec says should be done which is typically unnecessary (for example, did you know that every time you resolve a Promise with another Promise, that causes creation of a _third_ Promise that no one cares about) but can be observed from script in various ways (e.g. by messing with @@species) so are very hard to optimize out. Promises are also very gc-intensive as specified....
This is one of those cases (iterators being the other poster child) where the usual "yeah, people will just write complicated enough engines with complicated enough JITs to make this all perform OK enough" attitude of the ECMA committee is a bit annoying.
Comments
The funny part is that they _used_ to be completely in C++ (as part of Gecko, not SpiderMonkey). Then they were rewritten to be part of SpiderMonkey, and various bits were made self-hosted in the process. This turned out to be slower than doing it all in C++, for various reasons, some of which might be Gecko-specific (e.g. support for security wrappers).
But in general, optimizing promises as specified in ES6 is _really_ hard. There's all sorts of work that the spec says should be done which is typically unnecessary (for example, did you know that every time you resolve a Promise with another Promise, that causes creation of a _third_ Promise that no one cares about) but can be observed from script in various ways (e.g. by messing with @@species) so are very hard to optimize out. Promises are also very gc-intensive as specified....
This is one of those cases (iterators being the other poster child) where the usual "yeah, people will just write complicated enough engines with complicated enough JITs to make this all perform OK enough" attitude of the ECMA committee is a bit annoying.