User provided OPENJ9_JAVA_OPTIONS env var overrides OpenJ9 SCC options

[mpirvu]

#338 added the ability to embed a shared-class-cache (SCC) in OpenJ9 containers. This OpenJ9 JVM feature is enabled by setting the following env var:

ENV OPENJ9_JAVA_OPTIONS="-Xshareclasses:name=openj9_system_scc,cacheDir=/opt/java/.scc,readonly,nonFatal"

However, if the user runs an OpenJ9 container image with -e OPENJ9_JAVA_OPTIONS="..." it may inadvertently remove the options that enable the embedded SCC.

I see two possible solutions:

1. Append the user provided options to the ones set in the container
2. Use a different env var for setting OpenJ9 options in container (for instance JAVA_TOOL_OPTIONS which already is used)

Attn: @bharathappali @dinogun

[bharathappali]

Thanks for pointing it @mpirvu , I feel Append the user provided options to the ones set in the container will be a good approach as its a OpenJ9 specific option. Will look into it.

[mpirvu]

@bharathappali It would be ideal if we had a solution for this issue in the upcoming release. Thanks

[bharathappali]

@mpirvu As -Xshareclasses is an OpenJ9 specific option I feel it should be added to the OPENJ9_JAVA_OPTIONS, I do accept there are downsides as you mentioned it can be overridden, I feel its upto the user who is overriding it as he needs to be aware of the default settings exported in the docker image (User can add settings on top of default one). We have similar case with JAVA_TOOL_OPTIONS as well (It can also be overridden). But i do feel moving -Xshareclasses option to JAVA_TOOL_OPTIONS gives room for openj9 users to set OpenJ9 specific settings at ease with OPENJ9_JAVA_OPTIONS

I have raised a WIP PR #430 and would like to see the community to take call on the best possible resolution for the given problem.

Please correct me if any of my assumptions were wrong, Thanks in advance.

[mpirvu]

As -Xshareclasses is an OpenJ9 specific option I feel it should be added to the OPENJ9_JAVA_OPTIONS

I agree with this point

I feel its upto the user who is overriding it as he needs to be aware of the default settings exported in the docker image

I do not agree with this point. It's cumbersome for someone to lookup the container definition to see in detail what it does. In this case one would have to scan the git repo to find dockerfile_functions.sh file where the options are set.

Is there any downside to prepend the -Xshareclasses options to whatever the user provides? In this case the user can provide her options on top of the -Xshareclasses options from the container, or even override the Xshareclasses options from the container should she chose to do so.

[bharathappali]

It's cumbersome for someone to lookup the container definition to see in detail what it does

I do accept its an extra effort for a user to have a test run of image to check env and grep for OPENJ9_JAVA_OPTIONS to check the options set.

Is there any downside to prepend the -Xshareclasses options to whatever the user provides?

I might be wrong please correct me if I'm, The possible way i see is to add a startup script which reads the user provided env options and append -Xshareclasses to it after the container startup, which might increase the java startup time (It would be very minimal as its jus parsing the env option and setting an env option) after the container startup.

I'm not sure if docker has any option to set a ENV at build time which considers (holds up like a placeholder) runtime setting change, I need to take a look to check if its possible to make it via docker options.

[mpirvu]

I realize now that appending is not easily done. I'll leave the implementation up to you: either with a script or through JAVA_TOOL_OPTIONS.

[ymanton]

If we append SCC options how would the user override them if they needed to?

[bharathappali]

If we append SCC options how would the user override them if they needed to?

Thanks for raising this point, the SCC option should be prepended so if the user adds the -Xshareclasses it will be the later one (second occurrence) which will be taking effect if i'm not wrong.

To avoid these corner cases #430 adds SCC option to JAVA_TOOL_OPTIONS to keep it simple (Adding OpenJ9 specific option to JAVA_TOOL_OPTIONS is yet to be discussed)