Uwe Schindler

Thanks @rmuir for the clirifaction. To add, because also @mcimadamore asked: We use shared segments, because we only allocate and map the segment once. It is then used by multiple...

Closing this as the JDK 19 impl was merged (#912).

Linux Jenkins tests: https://jenkins.thetaphi.de/job/Lucene-jdk17panama-Linux/ Windows Jenkins tests: https://jenkins.thetaphi.de/job/Lucene-jdk17panama-Windows/

Hi, I executed luceneutil bench using jdk-17-ea+b25: ``` TaskQPS baseline StdDevQPS my_modified_version StdDev Pct diff p-value BrowseMonthTaxoFacets 1.00 (4.8%) 0.71 (6.7%) -29.1% ( -38% - -18%) 0.000 BrowseDayOfYearTaxoFacets 0.98 (5.9%)...

After analyzing the heap dumps provided by JFR, I was able to figure out what the problem is. Basically, all native, VarHandle backed methods are fast and optimize nice. But...

With my patch to bulk methods results look like this: ``` TaskQPS baseline StdDevQPS my_modified_version StdDev Pct diff p-value Respell 55.14 (0.9%) 40.97 (0.9%) -25.7% ( -27% - -24%) 0.000...

I did more testig and was able to make MMapDirectory work the same speed. This patch fixing the perf issue shows the problems: https://github.com/uschindler/lucene/commit/b057213cc6548ffa29b8e2810f39eb84c50a3bc0 The main issue can be seen...

Here is the results of the original pull request without the unsafe memory copy, using the `fromArray()` and slicing code. During runtime, the benchmark runs 72 seconds vs 60 seconds....

I also ran the same with tiered compilation turned on and no `-Xbatch` (java defaults). The results are much better, but still the heap allocations are done. For long-running benchmarks...

I opened https://bugs.openjdk.java.net/browse/JDK-8268743 about the object allocations.