Timeline for low profile memory calculator

[matthew-a-carr]

Hi Buildpack Team 👋

I wanted to ask if there was a timeline or any update on when the low-profile memory mode will be implemented for the Java memory calculator. I'm in the process of reviewing using Java buildpacks with a Spring Boot application and we're coming up on the same issue outlined in the RFC and would ideally prefer an OOTB solution implemented by the buildpacks team as apposed to us configuring JVM options when the available memory is below 1GB.

Thanks,
Matt

[dmikusa]

Sorry, I don't have a timeline. It is something that I'd like to get to, but I have a number of projects going on, and it's OSS/my spare time so I can't give any commitments.

If it's something you'd like to see, the best way to make this happen would be to contribute it. Happy to talk more if someone's interested in contributing to this. I have some ideas on how we can implement it, and I can share context/answer questions about the code base.

[matthew-a-carr]

Hi @dmikusa, apologies I didn't have a notification come through on the reply above.

If it's something you'd like to see, the best way to make this happen would be to contribute it. Happy to talk more if someone's interested in contributing to this.

I’d be keen to get involved with the Java buildpack maintenance/improvements such as the above. What's the best way to register my interest in this and who are the right people to speak to to understand how this is currently maintained?

[dmikusa]

That's fantastic! We're always looking for more help. You can check out this post for more details on contributing in general.

As for this particular issue, we can chat here about it or on Slack. Whatever you prefer.

The issue itself should be fairly well-defined in the RFC you linked to above, so please take a look through and let me know if you have any questions. I can help sort out any gray areas in the RFC.

Aside from that, the memory calculator code is in two places. The legacy code is in that library. It's kind of a pain to work with that library though because you have to make your changes & then go mod replace them into a buildpack, and finally package up the buildpack just to test them out. That code base is still there, but just for security/critical fixes. We're not doing feature work in that repo.

Going forward, we've combined the library and JVM vendor buildpacks all into one project. In this project, you can make changes & directly build a buildpack using libpak-tools. This transition is still in progress, so you need to use the specific branch I linked to for now, but working to get that merged and stabilized soon. Then you'll be able to just pull down the latest release of libpak-tools & build buildpacks.

My suggestion would be to start by getting the code checked out. Make sure you can build things and run a buildpack with your changes. After that, you can start making changes, writing unit tests, and then ultimately seeing them in action by building your own copy of the buildpack with your changes. When everything looks good, send up a PR. If you think the work is too much for a single PR, feel free to split things up and send multiple PRs.

Let me know if you have any questions about anything.