[jira] [Commented] (SOLR-7748) Fix bin/solr to work on IBM J9

["Shawn Heisey (JIRA)" <ji...@apache.org>]

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org