Jemalloc 5.3 estimated release time frame

[LifeIsStrange]

Hi,
I was wondering what is the next release date estimate ?

Looking at past releases:
https://github.com/jemalloc/jemalloc/releases
It looks like there was one major release per year but the 5.3 seems to be an outlier as it's already been ~1.5 year.

A not too long release cycle allow:

1. To bring improvments earlier to the community
2. to catch more performance regressions because of order of magnitude wider testing.
   Maybe that a one year old commit regressed performance on workload X by 15% but it's "too late" to find/bisect up to the commit that led to the regression. Or it could be hidden by an hortogonal optimization that bring a >= 15% optimization.
3. jemalloc is competing with other state of the art allocatrors such as mimalloc.
   Rustc has currently a PR that is evaluating migrating from jemalloc (for the compiler) to mimalloc by default.
   They are comparing in the benchmarks Jemalloc 5.2 from 2019 vs latest mimalloc from 2021.
   It would be unfortunate to loose such a big user of Jemalloc because of release date time frame contingencies as current jemalloc (master) might actually significantly outperform current mimalloc.

@interwq
@davidtgoldblatt

[davidtgoldblatt]

I'm loathe to say anything too specifically, because I've said "the next release is just around the corner" multiple times a bunch of times, and been proved a liar each time. However, we've like, actually started discussions for the next release in a more active way (e.g. "what should go in the changelog", "what settings flags should we flip", etc.).

(And, you're right -- I looked at the fast paths from the last public release compared to what's currently at dev head, and the new code is substantially better).

[jsteemann]

If there is the possibility to get a decent application speedup just by upgrading to a new version of the memory allocator, I am all for it.
So an official release, or at least an ETA for it, will be highly appreciated from my side too!

I would guess that will be true for many users that ship applications that bundle/link jemalloc.
Thanks a lot!

[kev009]

It would be nice to get it into FreeBSD too. We are going to miss the 13.0 release but it should be able to MFC for the next point release.

[egaudry]

If there is the possibility to get a decent application speedup just by upgrading to a new version of the memory allocator, I am all for it.
So an official release, or at least an ETA for it, will be highly appreciated from my side too!

I would guess that will be true for many users that ship applications that bundle/link jemalloc.
Thanks a lot!

I would also mention the fragmentation/ability to retrieve memory too.

[drjohnnyfever1]

It would be nice to get it into FreeBSD too. We are going to miss the 13.0 release but it should be able to MFC for the next point release.

I just did a test import of the tip of dev into FreeBSD main and cherry-picked into stable/13 and got it to build and work, at least on amd64. For some reason I don't totally understand I have to undef the pthread get/set name stuff even though it sort of seems like that should work. I might be doing something wrong, it's the first time I've tried this.

Would it be worth trying to track snapshots in main, and then merge whatever the latest release in tree is into stable sort of like what is being done with OpenZFS now?

[davidtgoldblatt]

I think that might make sense; that's (broadly) how we do releases to internal customers as well. We could also do a better job tagging "semi-stable" releases (i.e. those we're running in production) in this way.

[pvizeli]

Would be great to get a new release, ident. We use jemalloc for Home Assistant in all our containers. I'm happy to test a new semi-stable release.

[jsteemann]

Given that there hasn't been any release in the last 20 months and #2030 (comment) does not provide any details on the next release's ETA, I am wondering if it makes sense to expect a new release any time soon.

If there won't be a new release soon, do you think it makes sense for jemalloc users to use the current state of the dev branch, or are there any known issues with it from the maintainer point of view? Thanks!

[interwq]

It's still hard to promise a date; we are a small team and the covid situation isn't making things easier for us.

One thing mentioned is, we can share the commits we are running in production. It will only be tested on a couple of platforms (e.g. recent Linux + x64), but runs stable at large scale. We typically update our production version to dev every month or so. One such commit is 12cd13c.

If there are interests around that, I can create a separate thread and maintain the list of commits there. I'm inclined to say not adding official tags to these commits, as a way to discourage upgrading to them unconditionally.

[jsteemann]

Ok, thanks! If you could share the commits that are considered reasonably stable, that would be awesome!

[interwq]

Created #2060.

[Stephan202]

@interwq Tnx! In this issue you shared a relevant detail ("e.g. recent Linux + x64"). Perhaps it's useful for people checking #2060 to see a short (high level, ball park) description of what the "platforms tested and deployed" look like.

Regardless, thanks for sharing :)

[interwq]

re: platform details. Agree it would be useful. However there are a couple of reasons we probably cannot share more, 1) the configuration, including servers and OSes, can change at any time, and is out of our control; and 2) more details about our production environment, even ballparks, may start falling into the sensitive information category, which we certainly would like to avoid.

[paravoid]

Debian maintainer for jemalloc here, and I'm also interested in this question :) The next version of Debian ("bullseye") is going to be released in a couple of weeks (August 14th). Once that happens, a new development cycle will begin and it'd be nice to refresh jemalloc to a new major version and ideally relatively early in the cycle (first 6 months or so), especially given it's going to include about 2 years of commits. Thanks again for all of your work!

[kev009]

I do wonder why this is circuitous versus tagging normal releases at some interval like twice a year. A stable branch could follow it before the next major release in case there are any important bug fixes.

I'm considering working on providing https://github.com/microsoft/snmalloc as a src build option in freebsd main's libc since it seems like FB isn't as interested in working with FOSS maintainers or the origin as they used to on this.

[jasone]

@kev009, the existing infrastructure for integrating jemalloc into FreeBSD is capable of using both git hashes and tagged releases. And now that FreeBSD is using git, it is probably possible to substantially streamline what is already a low-effort integration mechanism (ignoring typical FreeBSD toolchain/platform churn). Fixes and enhancements have migrated both directions over the past few years, which suggests there are no fundamental barriers to collaboration.

It seems there is some FreeBSD committer interest in switching to snmalloc. The potential merits of integrating snmalloc are orthogonal to the particulars of tracking jemalloc; let's not confound the two.

[interwq]

@kev009 : we do value FreeBSD and certainly intend to support its use cases. For the context, the main reason of no releases after 5.2.1 was because no notable bugs were found. Also since then we have gradually switched to longer term projects towards 6.0, and initially had no plan of more 5.x releases.

That being said, after accumulating a number of performance optimizations, we started thinking and preparing for the 5.3 release. It indeed has been delayed several times because of various reasons, e.g. both full time developers had to leave for several months because of family reasons. Also because there are other long term projects in progress, we wanted to wait till they are in a reasonable shape, even if they won't be announced or enabled yet.

Right now it's only blocked on one of my projects, which I plan to wrap up around October. Either @davidtgoldblatt or myself will get to the release right after.

[eilandert]

Hello @interwq, any status on #2060 ?

[interwq]

@eilandert : I'd still suggest the most recent one (from July) in #2060. We have another one in the process but I prefer having it up in production for a while before sharing here.

For the 5.3 release, there's still one more feature (to detect use-after-free) I'd like to merge and then I'll get started on the release. We should be able to have the release candidate by end of Oct.

[interwq]

A quick update that we have started preparing for the 5.3 release. Still a few more PRs to merge, and then we will do an internal large scale test and share the RC in a separate thread.

[interwq]

Update: the 5.3 release candidate is in #2213.

[interwq]

5.3 released -- https://github.com/jemalloc/jemalloc/releases/tag/5.3.0