RFR: 8352075: Perf regression accessing fields [v28]

Johan Sjölen jsjolen at openjdk.org
Tue Jun 10 15:47:44 UTC 2025


On Tue, 10 Jun 2025 15:15:34 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> I think you misunderstand me, as what I'm proposing wouldn't requre creating an array in `create_search_table`.
>> 
>> I'm saying that you do this:
>> 
>> ```c++
>> // Note: we require the supplier to provide the elements in the final order as we can't easily sort
>> // within this method - qsort() accepts only pure function as comparator.
>> void PackedTableBuilder::fill(u1* table, size_t table_length, Supplier &supplier) const {
>>   Pair<uint32_t, uint32_t> kvs[4];
>> 
>>   size_t offset = 0;
>>   size_t len_read = 0;
>>   while (len = supplier.next(kvs, 4)) {
>>     // len tells you how many of the full capacity of kvs was used.
>>   }
>> }
>> 
>> 
>> Now each call of  `Supplier::next` gives you up to 4 elements, quartering the amount of virtual calls necessary.
>> 
>>>Alternatively, we could replace virtual calls with templated fill method. In that case the Comparator should be a template method as well, since that one is even more perf-critical?
>> 
>> Sure, you can try that out.
>> 
>> To be clear, I am only asking: Are virtual calls expensive enough here that not having them, or amortizing their cost, something that makes the performance better?
>
> The earlier version of this PR was not abstracting out PackedTable* so there were no virtual calls. In both the CCC.java and undisclosed customer reproducer I don't see a significant difference in performance - these involve whole JVM startup, so the efficiency of code with linear complexity is probably under the radar. If we want to optimize the hack out of it - yes, there would be space for that, maybe at the cost of maintainability and/or reusability.
> TLDR: I don't have a (micro)benchmark that would prove one thing is better than the other.

Alright, if you can't observe a difference then don't change a thing :-).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/24847#discussion_r2138248072


More information about the serviceability-dev mailing list