uschindler commented on PR #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-1264435295
Closing this as the JDK 19 impl was merged (#912).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-891655796
It works with build 33, every hour a Jenkins build tests it:
https://jenkins.thetaphi.de/job/Lucene-jdk17panama-Linux/ and
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-891211684
Hi,
> > Ca you post `java -version`and tell us if you maybe compiledyour own
version?
> > Hi @uschindler,
> > java --version
> > openjdk 17-ea 2021-09-14
> >
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-890520954
> Hi @uschindler,
> I get the following compilation errors when I build your patch (Gradle
build 6.3.8)
>
> > Task :altJvmWarning
> > NOTE: Alternative java
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866980038
> > But I think it would be improved by providing some more diagnostics
(LogCompilation or whatever, maybe JIT stats in the JFR output). Let it be a
"canary" to find little
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866967688
> > Here are the berlinbuzzwords slides about this:
https://2021.berlinbuzzwords.de/sites/berlinbuzzwords.de/files/2021-06/The%20future%20of%20Lucene%27s%20MMapDirectory.pdf
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866144962
Here are the berlinbuzzwords slides about this:
https://2021.berlinbuzzwords.de/sites/berlinbuzzwords.de/files/2021-06/The%20future%20of%20Lucene%27s%20MMapDirectory.pdf
--
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866142054
> > The problem with luceneutil is also that it respawns a JVM multiple
times.
>
> Hmm, we added multiple JVMs long ago precisely because HotSpot was so
unpredictable.
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866112156
> > This was negotiated today
> > To read the whole story check here: [openjdk/panama-foreign#555
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866088334
> > So the benchmarking will stay noisy unless we use JMH.
>
> Maybe we should switch `luceneutil` to JMH? Or, poach ideas from it? How
is it reducing JVM/hotspot noise
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866087762
Hi @mikemccand,
> > I have no idea why the facetting stuff at the beginning of the bench
output is so badly behaving with MMapDirectory#v2 on top of project panama,
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866054411
Hi @mikemccand,
I will open a few more issues in luceneutil. The way how it invokes the JVM
is not like it is done in production:
- `-Xbatch` as default doesn't help for
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-866013290
There is no fix for the JDK 17 issues with garbage collection and disabled
tiered compilation. From Java 18 on we can use the new MemoryCopy class to do
bulk copies. It also
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861496169
In the next Panama iteration, there will also be a ready-to use copy method,
which has same shape as methods added for bulk copy:
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861492558
The issue is confirmed and for the readBytes() code there's already a
workaround. Long term we will improve
For the float and long options: copyMemory() has some
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861362120
I opened https://bugs.openjdk.java.net/browse/JDK-8268743 about the object
allocations.
--
This is an automated message from the Apache Git Service.
To respond to the
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861265227
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
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861222097
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
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-861046986
I did more testig and was able to make MMapDirectory work the same speed.
This path shows the problems:
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860900058
With my patch to bulk methods results look like this:
```
TaskQPS baseline StdDevQPS my_modified_version
StdDevPct diff
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860889941
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.
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860731308
I used the wrong benchmark task (not wikimediumall but wikimedium10k,
copypastershitnwaste). New benchmarks coming soon.
--
This is an automated message from the Apache Git
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860665332
> I will now download the JFR files created by the tool and analyze them
locally.
No info from JFR files :-(
--
This is an automated message from the Apache Git
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860649214
I will now download the JFR files created by the tool and analyze them
locally.
--
This is an automated message from the Apache Git Service.
To respond to the message, please
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-860641916
Hi,
I executed luceneutil bench using jdk-17-ea+b25:
```
TaskQPS baseline StdDevQPS my_modified_version
StdDevPct diff
uschindler commented on pull request #177:
URL: https://github.com/apache/lucene/pull/177#issuecomment-856778316
Linux Jenkins tests:
https://jenkins.thetaphi.de/job/Lucene-jdk17panama-Linux/
Windows Jenkins tests:
https://jenkins.thetaphi.de/job/Lucene-jdk17panama-Windows/
--
This
26 matches
Mail list logo
