Revert MemBalancer GC pacer from 1.10 release

[d-netto]

There are a few issues which are possibly related to the new GC pacer (e.g. and #50705 and #50956).

Furthermore, the implementation currently in 1.10-beta2 and master seems to deviate from what has been originally implemented in v8 (see discussion in #50909).

Due to these reasons, we discussed in triage that it might be better to de-risk the release by reverting the MemBalancer implementation, but keep the per-page memory accounting introduced in that PR.

CC: @NHDaly, @gbaraldi, @vchuravy

[PallHaraldsson]

@d-netto it seems you're doing great work on the GC, and even with reverting this the GC in 1.10 will be very different from 1.9 (and also a bit different at least from 1.11).

Do you think this will be fixed and the MemBalancer will make it into 1.10, or some 1.10.x? (1.10 will become LTS I understand, maybe not though 1.10.0, and it seems bad if 1.11 and the LTS different regarding this/GC). I just heard of it and was looking at the paper, and it seems like a great idea for Julia (and GC in general, e.g. the web/V8, and in effect Julia and web browsers would "cooperate", without communication). [Do you know if it's in V8, that is Chrome, and Edge already, not just in a future stable version, since the paper is about a year old already.]

[NHDaly]

At JuliaCon, we talked about generally trying to move towards a more reliable release process for julia, with shorter and more consistent release cycles. Part of achieving that is to be stricter about holding the line on release protocol. Once we feature-freeze a release, we should not be porting new features back to it, we should only be backporting bug fixes. If a feature proves to be too complicated to fix, as in this case, we are going to try to be more diligent about dropping it from the release and trying again for the next release. I believe that is the plan here as well.

So no, i don't think membalancer will make it into 1.10.

Thankfully, as you point out, 1.10 comes with a bunch of great GC improvements! But improving julia's GC triggering heuristics will have to wait til the next release, I think. We still don't know whether membalancer is going to be right for julia or not, and we don't know what its performance characteristics will look like, since it's currently implemented incorrectly. Hopefully it does prove to be an effective choice though! :)

---

With all of that said; I'm not sure how the LTS figures into all of this. Maybe LTS releases can be more lenient with accepting new features / perf improvements in future point releases? I think this is less clear. Maybe something to reevaluate once a fixed membalancer lands on master.

[d-netto]

@KristofferC: what is the standard process to revert a feature from a release?

More specifically, I see two possible options to revert #50144:

• Directly revert from the 1.10 branch and open a PR to the 1.10 branch itself
• Revert it from master, and then add a "Backport to 1.10" label

Which one is preferable?

[PallHaraldsson]

I did not suggest delaying releasing 1.10.0, or getting the MemBalancer into it. I agree with shorter cycles. I suggest delaying new LTS until MemBalancer is in. It seems very important. When it is in 1.11 and stable, then it can go into 1.10.1 or 1.10.2, whatever we decide will be LTS (if anything...). It just seems bad to have a new LTS and just recently improving the GC and have two new implementation going forward that are not then the same.

I'm not sure about "more lenient" with LTS, I think the policy is only bugfixes and security fixes, for good reason.

[MarisaKirisame]

the author of MemBalancer paper here. lmk if there is anything I can help.

[vchuravy]

Revert it from master, and then add a "Backport to 1.10" label

Generally this. There are some cases where the former works better, but in this case revert on master, backport that and then reland at a later time.

[KristofferC]

It would be good to do this in a somewhat "timely manner" because we really want to start releasing RCs but it isn't really wise to do so in case the GC implementation is to still significantly change (due to the revert).

[vtjnash]

I think we just wanted to undo the backport, but not remove the code from master, right?

[ufechner7]

Related: #51589