+1 nb. It would be nice to no longer have to do work on a separate dependency for newer JDK versions. It sounds like it would make it simpler to do these updates in the future.
On Wed, Dec 10, 2025 at 11:52 AM Francisco Guerrero <[email protected]> wrote: > +1 > > On 2025/12/10 17:18:38 David Capwell wrote: > > +1. We don’t bump this dependency outside of JDK versions so being in > tree actually makes it easier for us to support newer JDK versions > > > > > On Dec 10, 2025, at 8:41 AM, Aleksey Yeshchenko <[email protected]> > wrote: > > > > > > +1 to bringing it in-tree. > > > > > >> On 10 Dec 2025, at 13:32, Ekaterina Dimitrova <[email protected]> > wrote: > > >> > > >> +1 if there are volunteers to do the work, that’s great > > >> > > >> On Wed, 10 Dec 2025 at 8:20, Dmitry Konstantinov <[email protected] > <mailto:[email protected]>> wrote: > > >>> +1 > > >>> > > >>> On Wed, 10 Dec 2025 at 13:12, Brandon Williams <[email protected] > <mailto:[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] > <mailto:[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 > > > > > > > >
