+1 if there are volunteers to do the work, that’s great On Wed, 10 Dec 2025 at 8:20, Dmitry Konstantinov <[email protected]> wrote:
> +1 > > On Wed, 10 Dec 2025 at 13:12, Brandon Williams <[email protected]> wrote: > >> Sounds good to me, let's bring it in. +1 >> >> Kind Regards, >> Brandon >> >> On Wed, Dec 10, 2025 at 6:47 AM Josh McKenzie <[email protected]> >> wrote: >> > >> > I think we should bring jamm in-tree. >> > >> > I spoke with Jonathan about this and he's good with either it being a >> single-shot donation to being in-tree on trunk or us going the more formal >> route of an ASF donation as a subproject in the C* ecosystem. I prefer the >> former as it'll make it easier to keep it up to date as we add new JDK >> support, verify CI, and we can still release it separately as another build >> target. >> > >> > Context: We rely on the jamm library to determine object sizes on heap >> and trigger some operations based on that. >> > - jamm: https://github.com/jbellis/jamm >> > - ObjectSizes.java in cassandra: >> https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/ObjectSizes.java >> > >> > The jamm project is in a good place from a hygiene perspective; >> Benjamin did a ton of work getting it up to snuff for JDK17. I have a PR >> for JDK21 support over there (link) but was able to work around even >> needing that by signaling to jamm not to calculate w/compressedOops, though >> in retrospect that documentation needs to be updated to reflect the >> coupling with using genZGC: >> https://github.com/jmckenzie-dev/cassandra/blob/jdk21_support/build.xml#L343-L344 >> > >> > So. What do we think? >> > > > -- > Dmitry Konstantinov >
