SOLR-16463 Provide a convenience jre11 image for 9.0

[janhoy]

https://issues.apache.org/jira/browse/SOLR-16463

I believe the merge of this PR will trigger image build and a new PR being created upstream at https://github.com/docker-library/official-images to add the extra image? @HoustonPutman

An alternative is to downgrade the main tag 9.0.0 but that seems a bit too disruptive, at least for 9.0, since people may use our image as source for their own stuff and assume JRE17...

Should be perhaps also make a note in README.md displayed at Docker Hub, to alert users of the issue and the workaround? Will a change to README.md in this repo automatically update the docs on docker hub?

[janhoy]

I think we need a patch to generate-stackbrew-library.sh too to process the variant.

[HoustonPutman]

I think we need a patch to generate-stackbrew-library.sh too to process the variant.

yeah we need to patch it unfortunately... Also I assume we want to explicitly tag both jre-11 and jre-17, and have either the 11 or 17 be the default.... This is going to triple the number of tags we have though...

It is really nice to support just one JRE. It's sad that we can't do that.

I'll try to find time in a few days to help with the stackbrew stuff.

[janhoy]

I'll try to find time in a few days to help with the stackbrew stuff.

Thanks. I see a comment in the stackbrew script about removing support for multi variants. But I gave it a shot by just adding a new variant to the loop, but that was not enough. We should probably keep the ability for such cases like this.

[henrik242]

I think it makes sense to make jre11 the default. Two separate teams in my organization stumbled upon this independently of each other, spending a lot of time debugging in the process.

[janhoy]

We could make jre11 the temporary default until the JDK bug is fixed. Then a -jre-17 tag should exist for those who depend on JDK17. But as soon as the JDK bug is fixed there is no need to provide jre11 for e.g. 9.2, is there?

[henrik242]

We could make jre11 the temporary default until the JDK bug is fixed.

Agreed!

But as soon as the JDK bug is fixed there is no need to provide jre11 for e.g. 9.2, is there?

Nope

[uschindler]

As mentioned on the issue. This bug affects caffeine not lucene in this case. I would not step back to JDK 11, it is much easier to fix this:

Pass -XX:CompileCommand=exclude,com.github.benmanes.caffeine.cache.BoundedLocalCache::put on Solr's command line. So basically we should document this and the docker image should just pass this parameter. -- Problem solved.

Uwe

[uschindler]

See my previous comment. We can stay with Java 17, just tell Hotspot not to compile the affected method.

[uschindler]

As mentioned on the issue. This bug affects caffeine not lucene in this case. I would not step back to JDK 11, it is much easier to fix this:

Pass -XX:CompileCommand=exclude,com.github.benmanes.caffeine.cache.BoundedLocalCache::put on Solr's command line. So basically we should document this and the docker image should just pass this parameter. -- Problem solved.

Uwe

This would also not backwards break people's own docker images based on the Solr 9.0 one.

[henrik242]

-XX:CompileCommand=exclude,com.github.benmanes.caffeine.cache.BoundedLocalCache::put

Just out of interest, what does this do? I'm afraid I'm not all that into JVM internals.

[uschindler]

If there are still other occurences of this, we can still jump back to 11, but let people first upgrade and/or use the compile command. This is based on the reports on Solr's mailing list. Unfortunately not all of them posted the whole hserr file. Please ask them to always post especially the line after "Current CompileTask:", the other parts of the hserr file are not really useful.

[uschindler]

-XX:CompileCommand=exclude,com.github.benmanes.caffeine.cache.BoundedLocalCache::put

Just out of interest, what does this do? I'm afraid I'm not all that into JVM internals.

Hotspot fails while compiling that method. You see this in the Solr user reports. The line "Current CompileTask:" is important. Based on that information your can tell Hotspot to exclude that method from optimization. That is what this command line parameter does. It excludes the reported "bad method" from optimization by C2 completely.

See documentation: https://docs.oracle.com/en/java/javase/17/docs/specs/man/java.html#advanced-jit-compiler-options-for-java

For the Lucene's incarnation of this bug this prevented crushes in Jenkins - as expected.

[henrik242]

Based on that information your can tell Hotspot to exclude that method from optimization

So it's excluded from optimization, not from compilation altogether. Makes sense, thanks!

(Also linking to the caffeine issue for completeness)

[uschindler]

Based on that information your can tell Hotspot to exclude that method from optimization

So it's excluded from optimization, not from compilation altogether. Makes sense, thanks!

(Also linking to the caffeine issue for completeness)

From the standpoint of Hotspot it excludes it from compilation to assembly code.

From standpoint of end-user: yes, you're right.

[janhoy]

Abandoning