[
https://issues.apache.org/jira/browse/LUCENE-7966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16183010#comment-16183010
]
Uwe Schindler edited comment on LUCENE-7966 at 9/27/17 6:15 PM:
----------------------------------------------------------------
[~dweiss]: The patched class files are actually easier to maintain, as we do
not need Java 9 to compile, no duplicate class files in source folder, or some
fake Java 9 signature files (with questionable license) on bootclasspath (see
my previous branch). This was the main reason to rewrite the class files
instead of maintaining multiple source files. It's just a nice side-effect to
no longer need the delegation methods. So I personally like the patching
approach much more, as it's well tested by the ASM maintainers (we just use
their code, no custom impl). It would be horrible if we'd instead require all
committers to have both Java 8 and Java 9 installed!
The question here was just for confirmation and comparison of both approaches,
if they have some side effects.
bq. The slowdown on pic (the most compressible file) is reproducible
[~jpountz]: The one with biggest slowdown on Java 8 is the one with biggest
speedup in Java 9. The reason is quite clear: The Java 8 implementation by
Robert does more checks than the "old" LZ4 implementation (for safety and to be
compatible with new Java 9 impl). But on Java 9 the new method used is an
intrinsic, so we have a huge perf win!
was (Author: thetaphi):
[~dweiss]: The patched class files are actually easier to maintain, as we do
not need Java 9 to compile, no duplicate class files in source folder, or some
fake Java 9 signature files (with questionable license) on bootclasspath (see
my previous branch). This was the main reason to rewrite the class files
instead of maintaining multiple source files. It's just a nice side-effect to
no longer need the delegation methods. So I personally like the patching
approach much more. It would be horrible if we'd require all committers to have
both Java 8 and Java 9 installed!
The question here was just for confirmation and comparison of both approaches,
if they have some side effects.
bq. The slowdown on pic (the most compressible file) is reproducible
[~jpountz]: The one with biggest slowdown on Java 8 is the one with biggest
speedup in Java 9. The reason is quite clear: The Java 8 implementation by
Robert does more checks than the "old" LZ4 implementation (for safety and to be
compatible with new Java 9 impl). But on Java 9 the new method used is an
intrinsic, so we have a huge perf win!
> build mr-jar and use some java 9 methods if available
> -----------------------------------------------------
>
> Key: LUCENE-7966
> URL: https://issues.apache.org/jira/browse/LUCENE-7966
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other, general/build
> Reporter: Robert Muir
> Labels: Java9
> Attachments: LUCENE-7966.patch, LUCENE-7966.patch, LUCENE-7966.patch,
> LUCENE-7966.patch, LUCENE-7966.patch
>
>
> See background: http://openjdk.java.net/jeps/238
> It would be nice to use some of the newer array methods and range checking
> methods in java 9 for example, without waiting for lucene 10 or something. If
> we build an MR-jar, we can start migrating our code to use java 9 methods
> right now, it will use optimized methods from java 9 when thats available,
> otherwise fall back to java 8 code.
> This patch adds:
> {code}
> Objects.checkIndex(int,int)
> Objects.checkFromToIndex(int,int,int)
> Objects.checkFromIndexSize(int,int,int)
> Arrays.mismatch(byte[],int,int,byte[],int,int)
> Arrays.compareUnsigned(byte[],int,int,byte[],int,int)
> Arrays.equal(byte[],int,int,byte[],int,int)
> // did not add char/int/long/short/etc but of course its possible if needed
> {code}
> It sets these up in {{org.apache.lucene.future}} as 1-1 mappings to java
> methods. This way, we can simply directly replace call sites with java 9
> methods when java 9 is a minimum. Simple 1-1 mappings mean also that we only
> have to worry about testing that our java 8 fallback methods work.
> I found that many of the current byte array methods today are willy-nilly and
> very lenient for example, passing invalid offsets at times and relying on
> compare methods not throwing exceptions, etc. I fixed all the instances in
> core/codecs but have not looked at the problems with AnalyzingSuggester. Also
> SimpleText still uses a silly method in ArrayUtil in similar crazy way, have
> not removed that one yet.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
