All users were logged out of Bugzilla on October 13th, 2018

[meta] GC: Get GenerationalGC working on JaegerMonkey

RESOLVED DUPLICATE of bug 851057

Status

()

RESOLVED DUPLICATE of bug 851057
6 years ago
6 years ago

People

(Reporter: terrence, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:t])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 633166 [details] [diff] [review]
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.
(Reporter)

Updated

6 years ago
Depends on: 764961
Whiteboard: [js:t]

Comment 1

6 years ago
Is this bug going to happen with JM nearing extinction?
(Reporter)

Updated

6 years ago
Depends on: 851057
> 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.)
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.
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).
(Reporter)

Comment 5

6 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 851057
You need to log in before you can comment on or make changes to this bug.