+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

Reply via email to