Closed Bug 431908 Opened 12 years ago Closed 12 years ago

ActionMonkey: Use Tamarin Tracing's strings to implement SpiderMonkey strings


(Core :: JavaScript Engine, defect)

Not set





(Reporter: jimb, Unassigned)



Once we have Tamarin Tracing in the ActionMonkey tree, our first step should be to change SpiderMonkey to use TT's strings.

This will regress performance, as TT strings don't have SM's optimizations (deflated string cache; quick append; quick substring), but taking this smaller step allows us to do full in-browser tests sooner.  Bug 427154 should restore that performance.
Hi Jim, I'm wondering if this is taking too much risk in one gulp. The problems include lack of test coverage (we have a lot, but nothing near total), including performance tests.

Ideally we would have a near-to-release-shape state of ActionMonkey, near meaning a month or two. Is this even close to true now with ActionMonkey as it is? Even if not, every large calculated regression requiring multiple followup fixes takes us farther away from that point. I've seen projects lose the thread and never get back to near the (undertested, but user-tested in perma-beta) quasi-releasable point.

Why is it a goal to run in-browser JS tests on TT string code as it is today?

I again thought we were doing this the other way 'round: giving TT the spidermonkey string optimizations, and *then* unifying the types. Am I confused again? Bug 427154
Rob Sayre, Brian Crowder, Jason Orendorff, and Jim Blandy had a meeting in person about this strategy this morning; we'll be posting to tamarin-devel, and meeting again with more information tomorrow.

Rob explained to Jason and Jim that Mozilla's experience is that any performance regression at all, even temporarily, is a losing strategy.  So we'll be working with that constraint.
today's spidermonkey vs. tamarin-tracing numbers:
Mass-WONTFIXing ActionMonkey bugs.
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.