+1 I would prefer a separate sub project given jamm seems to have a decent user base, but im not going to vote against it if we dont.
On Thu, Dec 11, 2025 at 1:46 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 <https://github.com/jbellis/jamm/pull/71>) 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? >
