V8引擎是否对类实例执行逃逸分析？类实例与普通对象的逃逸分析差异及临时实例分配优化疑问

Great question—let’s break down what’s happening here, since this touches on some of V8’s optimization internals that aren’t always obvious.

Does V8 perform escape analysis on class instances? #

Short answer: Yes, and there’s no fundamental technical barrier making class instance escape analysis harder than for plain objects. V8’s escape analysis and scalar replacement optimizations work for both plain objects and class instances—though there have been historical differences in how aggressively these optimizations are applied to each, depending on the V8 version.

Why did your test show a difference? #

Your observation about shorter assembly and fewer operations for plain objects vs. class instances comes down to how V8’s optimizer handles object literals vs. class constructors in older versions (the one you tested):

• Plain object literals ({x: ..., y: ...}) are extremely straightforward for V8 to analyze. The optimizer can easily track that the intermediate objects never escape the function (you only ever access their x property at the end), so it can perform scalar replacement: it eliminates the object entirely, treating x and y as separate register variables. This is why you only see one multiplication—all the calculations get merged into a single (a.x + b.x) * 5 operation, no object allocation needed.
• Class constructors (new P(...)) require V8 to inline the constructor first before it can do scalar replacement. In older V8 versions, the optimizer was less aggressive about inlining simple class constructors compared to object literals. Without inlining, V8 can’t see that the instance doesn’t escape, so it has to allocate the temporary object, compute both x and y values and store them in memory, then read them back for the multiply operation—hence the two vmulsd instructions you saw.

Can the temporary class instance allocation be avoided? #

Absolutely! In modern V8 versions (used in recent Node.js releases), the optimizer will inline your simple P constructor without issue. Once inlined, it can detect that the intermediate P instances never escape the function, perform scalar replacement, and eliminate the temporary allocations entirely. The assembly output would then match (or be nearly identical to) the plain object version.

A quick note on your test setup #

Your test is on the right track, but keep in mind that V8’s optimizations are heuristic-based:

• Class constructors need to hit the same optimization thresholds as other functions (like being called enough times) before they’re considered for inlining.
• Older versions had stricter rules for inlining class constructors, which is why you saw the discrepancy.

Final Takeaways #

• No fundamental barrier exists for class instance escape analysis in V8.
• The difference in your test is a version-specific optimization detail, not an inherent limitation of class instances.
• Temporary allocations for short-lived, non-escaping class instances can be fully eliminated in modern V8.

内容的提问来源于stack exchange，提问作者Doofus