RFR: 8352075: Perf regression accessing fields [v28]

Johan Sjölen jsjolen at openjdk.org
Tue Jun 10 14:32:37 UTC 2025


On Tue, 10 Jun 2025 13:45:52 GMT, Radim Vansa <rvansa at openjdk.org> wrote:

>> This was done this way with a "Supplier" because this package would be useful for other Unsigned5 packed types.
>
> But then you'd need create an array of `Pair` in `create_search_table` and copy the data into that. You wouldn't need a Supplier at all, just pass the array and its length to the `fill` method. If you are worried about the virtual calls, I could do that.
> 
> 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?

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?

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

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


More information about the hotspot-dev mailing list