Re: Lucene benchmarks against JDK 25

Hi,

Am 26.08.2025 um 17:07 schrieb Chris Hegarty:
> Thanks Uwe.
>
>> There we only use it to keep track of attributes and how to construct them. In that case it is "write-once, read-many" and items are never deleted.
> This is the key information. IIUC, the JDK performance regression is only triggered by removal - and since we don’t remove, then I would expect Lucene to be unaffected by it.

That's also how I interpreted it. But when reading the PR that is 
applied as fix for 25.0.3 and 26, the magic is done on "get". So I am 
not fully sure how this behaves in reality. But I don't expect real 
performance problems on plain computeValue and later gets, because most 
of the lambda-related stuff (like a type cache) in the JDK also depends 
on ClassValue to keep track of implementation classes. They have similar 
patterns like our's: we keep track of a MethodHandle to the constructor 
of an attribute implementation class (and MethodHanles use ClassValue to 
lookup some MethodHandles vor varargs handling, too: 
https://github.com/openjdk/jdk/blob/075ddef831f059cad1639bb6834a0923e725e15f/src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java#L705-L711). 
So pure computeValue with only gets() looks unaffected, otherwise they 
would have seen it earlier.

I think Elasticsearch's Painless also has LambdaMetaFactory-like caches 
like this and those should be unaffected, too.

I think most of the code using ClassValue won't be affected, because the 
normal usage pattern is to attach something to classes for their 
lifetime (like Groovy attaches its Metadata) and never remove them 
again. When classes are unloaded the values are freed, too (and this is 
why it was invented to not need to use Class-keyed crazy weak maps).

Uwe

> -Chris.
>
>> On 26 Aug 2025, at 14:11, Uwe Schindler <[email protected]> wrote:
>>
>> Hi,
>>
>> We don't use ClassValue too extensively, only at one place: The only use of ClassValue is in TokenStream's attribute management. There we only use it to keep track of attributes and how to construct them. In that case it is "write-once, read-many" and items are never deleted. So basically when a TokenStream is constructed and attributes are added, we keep track of the implementations responsible for all attribute classes.
>>
>> Uwe
>>
>> Am 26.08.2025 um 14:19 schrieb Luca Cavanna:
>>> Hey all,
>>> I was wondering if anyone ran Lucene benchmarks against JDK 25 so far.
>>>
>>> Based on another thread in this same list, I would assume that we ran successful tests but no benchmarks yet. Would it make sense to set this up yet or is it too early?
>>>
>>> In particular, I have some questions about https://bugs.openjdk.org/browse/JDK-8358535 and whether it may impact Lucene.
>>>
>>> Cheers
>>> Luca
>>>
>>>
>> -- 
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: [email protected]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
-- 
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: [email protected]