Uwe Schindler
Uwe Schindler
The problem here is that we just reducing the number of guard checks and at same time raising the risk to segv: ReadVint uses multiple atomic reads and all of...
The param must go away or change - to +. Mike's commit fixed the tiered compilation problem and I was not sure if you have used his latest commit. To...
Hi @gf2121, thanks for taking the time to test more. It looks really like the guard checks are not affecting the whole thing, but as always we don't really know...
I think about this: ```java @Override public final int readVInt() throws IOException { try { // using #position instead of #mark here as #position is a final method int pos...
> I wonder if one reason why this helps is because this method is so large that it is prevented from inlining sub function calls. The JVM bug that affected...
We should maybe convert all of them back to loops in DataInput base class and remove the specializations and do more tests. I think the change here is then completely...
I will try out the same on `MemorySegmentIndexInput` (#518).
I was also thinking about the following: Why not make readVInt/readVLong final in the DataInput class? This should be possible after the refactoring in #602 ! We should also make...
Although it is unrelated, but could you make that one final for consistency? https://github.com/apache/lucene/blob/97d669bcdb5e302a4fd79c648d5f621d90a9ac3b/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java#L140 readFloats() is final but not readLongs()
OK, thanks, so let's keep the hack.