uschindler commented on PR #13146: URL: https://github.com/apache/lucene/pull/13146#issuecomment-2140957329
> Thanks Uwe! I suppose I blame the JDK then :-) I question how bad the venerable ByteBufferIndexInput was to warrant removing it over the potential improvement value of better memory management with MemorySegment API. After all we have other Directory impls, etc. for a variety of use-cases/scenarios, why not ByteBufferIndexInput within MMapDirectory too? It was removed because it is unsafe (it can crash your JVM) and with current JEPs in development it will no longer work in JDK 24 because sun.misc.Unsafe will go away and therefor unmapping won't work anymore. So basically we get rid of unsafe and code which is no longer supported. I am planning to open JDK issues because from the code, it should not slow too much. But it looks like of a side effect that it sometimes deoptimizes code on concurrent access on the safepoint. I will check about this with Maurizio. It could possibly only a bug in Java 21/22. So actually this is the reason why we have the sysprop in 9.x so we can detect such bugs, report it to JDK and let it fix those bugs. So please share more information or a small bench showing the problem. In typical Elasticsearch use cases we have seen no slowdown, but more a speedup. But on the other hand we did not close the IndexInput 10 times per second while punching on them from 64 threads. -- 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 to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
