There is still MT code in extensions. There is at least 2 dups for this bug open right now. I would love to get rid of LOCK/UNLOCK, but there is no consensus for doing that without an alternative mechanism. The only alternative on the table are the MT proxies, and not even I like them.

Is the 7% on V8 tripping a GC threshold on splay or earley-boyer (do you get the same # of GCs with and without the patch?). Each GC on splay is 5% of the total V8 runtime (SS shell harness version) on my machine IIRC.

(In reply to comment #2)
> (In reply to comment #1)
> > The patch I used to get those numbers.
>
> Can we get rid of dropProperty as well, now?
We could but the real win is to switch to an ES5-like MOP. That will entail other changes, so we should have a plan and check it twice.
/be

The patch makes earley-boyer do one less GC, from 2 to 1.
It doesn't affect the number of GCs done by raytrace or splay. (Each just does 1 during the test. I don't count the GC_LAST_CONTEXT GC, which happens as we shut down the shell, after the timing is done and the result is printed.)

(In reply to comment #9)
> The patch makes earley-boyer do one less GC, from 2 to 1.
>
> It doesn't affect the number of GCs done by raytrace or splay. (Each just does
> 1 during the test. I don't count the GC_LAST_CONTEXT GC, which happens as we
> shut down the shell, after the timing is done and the result is printed.)
Could you re-run the test with adding 4 words of pads instead of the title to the object. It would be interesting to know if the win comes from smaller objects or eliminating OBJ_LOCK/UNLOCK.

(In reply to comment #6)
> Let's do MT proxies.
Do you mean patching the object class dynamically to make it MT? That would be rather hazardous as in quite a few places the code assumes that class does not mutates. Fixing just Proxy.fix to work reliably took a lot of efforts.

(In reply to comment #11)
> (In reply to comment #6)
> > Let's do MT proxies.
>
> Do you mean patching the object class dynamically to make it MT? That would be
> rather hazardous as in quite a few places the code assumes that class does not
> mutates. Fixing just Proxy.fix to work reliably took a lot of efforts.
I mean fixing bug 566951. We are using proxies and becomes in our security wrappers and we fixed those poor assumptions. We are not going back on that.
/be

Discussed this with Brendan on IRC. In a sec, I'll post in bug 566951 about the requirements there.
But in short: let's get this patch landed before it bitrots. We're not going to leave 7% on the table; this should go in, and there's no point delaying it.
As brendan points out, we need to make the right defensive moves so that existing extensions and xulrunner apps don't just start crashing or mysteriously misbehaving. But we can do it in any order during the betas.

Win won't be nearly 7% once the GC schedule status quo ante is restored, I bet. Gregor and Igor are on that case, though (makes me hopeful we can move Shapes into the GC heap without another round of just-so-story tuning of GC thresholds to keep benchmarks unregressed).
/be

I understand. Thank you for clarifying this.
FWIW, this may be (another) good reason to modify the shell (or, even better, the testing methodology AWFY is based upon) to be more representative of the actual browser product, since nobody is going to end up running a shell when all is said and done.
...end of bug spam...

Paul: the goal is to make browser as fast as shell, not lumber shell with old browser overhead.
The JS_THREADSAFE costs are going away, but this bug may not be enough. The GC schedule can differ between browser and shell for less obvious reasons that the object size being bigger in browser due to JS_THREADSAFE.
/be

This should not have landed with an exception is dispatch that rejects cross thread closures. I suggested that in irc :-/ I will file a bug to add the exception so we at least get a handle on the problem and know where it happens.

(In reply to comment #26)
> This should not have landed with an exception is dispatch that rejects cross
> thread closures. I suggested that in irc :-/ I will file a bug to add the
> exception so we at least get a handle on the problem and know where it happens.
You are right. Mea culpa.