← All issues

JSC: inline allocation for Promise.resolve(non-thenable)

b1a6241

+function resolveObject(o) { return Promise.resolve(o); }
+noInline(resolveObject);
+// Watchpoint-invalidation scenario:
+function Proto() { }
+function resolveProto(o) { return Promise.resolve(o); }
+// Later: Proto.prototype.then = async function() { ... }

ConstantFoldingPhase uses condition-set watchpoints to prove an object's prototype chain has no then property, making it a non-thenable. Previously, when proven, it still emitted NewResolvedPromise with a clobberTop() C-call to operationNewResolvedPromise, defeating the optimization potential. This commit threads an isResolvedValueKnownNonThenable flag through the node so proven-object arguments produce inline allocation; clobberize narrows from clobberTop() to HeapObjectCount, and the abstract interpreter propagates a sharper inferred type.

The clobberize change from clobberTop() to HeapObjectCount is a significant alias-analysis loosening that lets store elimination, LICM, and GVN reason past the node — but it depends on the inline allocation truly having no side effects beyond allocation.

🔒

The watchpoint-guarded flag and the loosened alias modeling both create edge cases at JIT deopt boundaries worth examining closely.

더 확인하려면 구독해 주세요