[
https://issues.apache.org/jira/browse/SOLR-7748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14612038#comment-14612038
]
Shawn Heisey commented on SOLR-7748:
------------------------------------
There are severe bugs that happen in Lucene when using IBM's Java. I seem to
recall seeing something indicating that IBM is starting to take them seriously,
but that might have been wishful thinking.
It will be quite a while after IBM fixes the problem (if they ever do) before
there is widespread penetration of fixed Java versions, so until that happens,
the fact that bin/solr doesn't work right might actually be a good thing.
As I understand it, the J9 problems occur because IBM is extremely aggressive
at turning on optimizations in the JVM. The performance of IBM's Java is
legendary as a result of this, but it also causes a lot of problems.
I know that in at least one case of a bug with J9, there is an optimization
that can be turned off to fix the problem ... there may be other bugs fixed by
turning off certain optimizations.
As an initial step, I was thinking about having the startup script detect J9
versions and abort with a message indicating serious JVM bugs (perhaps linking
to the JavaBugs page on the Lucene wiki). We already have detection for Java
7u40 through 7u51, which enables the -XX:-UseSuperWord option for Java and
prints a warning to the user about upgrading Java.
As we learn more, we could start with commandline options to work around the
problems, and then if IBM ever actually fixes the problems, run normally with
those detected versions.
The java version detection currently happens in the script, which I think may
be a little fragile. Perhaps a tiny little Java program could be written to
detect a whole range of information about the JVM and return one or more known
strings back to the script to tell the script what to do . Those actions might
include aborting because the java version is not new enough, issuing a warning
because it's not 64-bit, turning on X and/or Y commandline options, etc. We
might even be able to set the max heap according to the available memory, but
do so less aggressively than Java itself does.
This comment turned into quite a lot of text! I started off just writing a
quick note about J9 bugs.
> Fix bin/solr to work on IBM J9
> ------------------------------
>
> Key: SOLR-7748
> URL: https://issues.apache.org/jira/browse/SOLR-7748
> Project: Solr
> Issue Type: Bug
> Components: Server
> Reporter: Shai Erera
> Assignee: Shai Erera
> Fix For: 5.3, Trunk
>
> Attachments: solr-7748.patch
>
>
> bin/solr doesn't work on IBM J9 because it sets -Xloggc flag, while J9
> supports -Xverbosegclog. This prevents using bin/solr to start it on J9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
