JSOP_NEW is not optimized, so we're entering the VM and re-entering baseline (or ion) for each of these. Fix.

New patch with fixes: previous one forgot to mark the Callee in the ICCall_NewScripted stub.

Comment on attachment 710335 [details] [diff] [review] Patch 2. Review of attachment 710335 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/ion/BaselineIC.cpp @@ +3198,5 @@ > +typedef bool (*CreateThisFn)(JSContext *cx, HandleObject callee, MutableHandleValue rval); > +static const VMFunction CreateThisInfo = FunctionInfo<CreateThisFn>(CreateThis); > + > +bool > +ICCall_NewScripted::Compiler::generateStubCode(MacroAssembler &masm) I think we can avoid a lot of code duplication if we use the Call_Scripted stub for JSOP_NEW as well (Ion's LCallGeneric also works with both constructing and non-constructing). We can make getKey encode the isConstructing bit, and wrap the CreateThis and check-return-type-is-primitive parts in an "if (isConstructing)" or something. Would you mind giving this a try? I think it would be really nice if we can make it work.

I thought about doing this, but the main issue I have with it is that register usage gets really tight on x86. The combined version may have a couple of extra pushes or pops, but I suppose that's not too bad of a price to pay. I'll look into it.

Fixed up to reuse code for ICCall_Scripted.

Comment on attachment 710920 [details] [diff] [review] Patch 3. Review of attachment 710920 [details] [diff] [review]: ----------------------------------------------------------------- Looks great.