+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
