Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Support for Jemalloc w/o Separate Build Pack #1487

Open
ksylvest opened this issue Jul 22, 2024 · 1 comment
Open

Feature Request: Support for Jemalloc w/o Separate Build Pack #1487

ksylvest opened this issue Jul 22, 2024 · 1 comment

Comments

@ksylvest
Copy link

Does the team maintaining this buildpack have any interest in a PR to install jemalloc by default / set a LD_PRELOAD env variable w/ this buildpack? It seems like a more sensible default to include (especially since the latest versions of Rails are shipping w/ it installed via Docker):

https://github.com/rails/rails/pull/50943/files

@schneems
Copy link
Contributor

The reason given is to reduce memory fragmentation. We're mitigating that in glibc via setting this environment variable by default https://github.com/heroku/heroku-buildpack-ruby/blob/633a1d170155c279e4a5803fc8352d93108ec1b9/changelogs/v205/malloc.md?plain=1.

I'm possibly interested in exploring doing something with jemalloc, but I think there are more caveats than that PR you linked to would lead you to believe. (Or at least I remember there being some caveats last time I looked into it).

I wouldn't do it here. I would do it on https://github.com/heroku/buildpacks-ruby which is the future. The path forward would look like: Making our own jemalloc buildpack, and then optionally requiring it to run before heroku/ruby based on some detection logic and making it disable-able as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants