764876 - [meta] GC: Get GenerationalGC working on JaegerMonkey

Status: RESOLVED DUPLICATE of bug 851057

(Core :: JavaScript Engine, defect)

Description

[Terrence Cole [:terrence]]

Attachment: Bitrotted, but previously mostly working heap barriers for JaegerMonkey.

There are several things to do here including: allocating from the Nursery, fast low-level heap barriers (e.g. don't stub-call like the attached patch does), inserting the inline assembly in the right places, etc.

Comment 1

[Paul Wright]

Is this bug going to happen with JM nearing extinction?

Comment 2

[Cameron Kaiser [:spectre]]

> Is this bug going to happen with JM nearing extinction?

I'm more curious to know JM+TI's life expectancy in general; we're still trying to get the PowerPC Ion port off the ground. (If JM+TI still operated going into Fx24, that would buy us time on the ESR.)

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

I don't think we'll be maintaining JM+TI into the GGC era. AFAIK most of the intergation work has been just turning off pieces that aren't compatible.

The plan is to disable JM+TI once the baseline compiler lands (scheduled for Fx23), but keep it in the tree for one release, in case we need to pref it back on in an emergency. Ideally it'll be removed in the following release (Fx24).

There is significant technical debt around JM and we'd prefer not to maintain it any longer than necessary. We could consider keeping the code around, and having a compile-time pref so at least the code isn't part of the build anymore. We could also consider just removing the more complex parts early (like inlining) and doing a full removal later.

Comment 4

[Cameron Kaiser [:spectre]]

It would also kill the MIPS and SPARC JITs since those don't have Ion backends either (though to be fair I don't know if anyone at Snoracle is even working on Mozilla stuff anymore). I would gladly accept a compile time pref in ESR24; I certainly understand the technical debt, recalling the end of TraceMonkey. Any bugs to watch would also be appreciated.

Meanwhile we'll try to step up our efforts to make the deadline, but there's only a few of us working on it, so it's slow progress (especially since it's not our front end, of course).

Comment 5

[Terrence Cole [:terrence]]

This bug is mostly about GGC. I think low-latency collection is much less of a requirement if you don't also have IonMonkey. Even if JM is still being used on MIPS/SPARC when we enable GGC on trunk, it should be fine to just build with GGC off for MIPS/SPARC.

With this caveat, I think it is perfectly fine to alias "working with JM" to "does not crash with JM". Brian's work in Bug 851057 is adequate for these purposes.