JDK-8039152 : Need a way to suppress message when picking up JAVA_TOOL_OPTIONS
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 9
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2014-04-03
  • Updated: 2020-02-10
  • Resolved: 2014-05-03
Related Reports
Relates :  
JDK-8036621 - Backport of: JDK-4787931/6519127 : System property
Relates :  
JDK-4971166 - JAVA_TOOL_OPTIONS environment variable
Description
There should be an option to suppress message when hotspot picks up the JAVA_TOOL_OPTIONS environment option.

The easiest way is to introduce an option which when passed among others will turn off the message output.
Comments
This will not be implemented, as it may introduce a vulnerability
03-05-2014
The JAVA_TOOL_OPTIONS variable was added via the following: JDK-4971166 JAVA_TOOL_OPTIONS environment variable with these deltas: D 1.255 04/02/16 00:20:33 rfield 706 705 00020/00019/02137 MRs: COMMENTS: 4971166: add the JAVA_TOOL_OPTIONS environment variable -- part II D 1.251.1.3 04/02/12 20:56:20 rfield 704 703 00020/00024/02121 MRs: COMMENTS: 4971166: changes per review -- add the JAVA_TOOL_OPTIONS environment variable D 1.251.1.2 04/02/11 21:19:35 rfield 703 700 00102/00017/02043 MRs: COMMENTS: 4971166: add the JAVA_TOOL_OPTIONS environment variable
08-04-2014
Adding more history. The _JAVA_OPTIONS variable support was added by this delta: $ sp -r1.103 src/share/vm/runtime/arguments.cppsrc/share/vm/runtime/SCCS/s.arguments.cpp: D 1.103 99/10/13 16:44:07 steffen 313 310 00083/00028/00670 MRs: COMMENTS: Recognize _JAVA_OPTIONS env var That support included adding the "Picked up _JAVA_OPTIONS..." message. Unfortunately, there is no bug ID associated with that delta so I can't determine the rationale around the various decision.
08-04-2014
The code that issues this message is here: src/share/vm/runtime/arguments.cpp: 3357 jint Arguments::parse_options_environment_variable(const char* name, Sys ClassPath* scp_p, bool* scp_assembly_required_p) { <snip> 3362 // The variable will be ignored if it exceeds the length of the buffer . 3363 // Don't check this variable if user has special privileges 3364 // (e.g. unix su command). 3365 if (os::getenv(name, buffer, sizeof(buffer)) && 3366 !os::have_special_privileges()) { 3367 JavaVMOption options[N_MAX_OPTIONS]; // Construct option array 3368 jio_fprintf(defaultStream::error_stream(), 3369 "Picked up %s: %s\n", name, buffer); Handling for both "_JAVA_OPTIONS" and "JAVA_TOOL_OPTIONS" is done by parse_options_environment_variable() and it is done carefully because this is a dangerous feature. Normally, the "VMOutput" family of options can be used to control messages from the VM that folks find annoying: $ egrep 'VMOutput|LogFile' src/share/vm/runtime/globals.hpp "Log compilation activity in detail to LogFile") \ product(bool, UseGCLogFileRotation, false, \ product(uintx, NumberOfGCLogFiles, 0, \ product(uintx, GCLogFileSize, 8*K, \ "GC log file size, requires UseGCLogFileRotation. " \ diagnostic(bool, SerializeVMOutput, true, \ "Use a mutex to serialize output to tty and LogFile") \ diagnostic(bool, DisplayVMOutput, true, \ "Display all VM output on the tty, independently of LogVMOutput") \ diagnostic(bool, LogVMOutput, false, \ "Save VM output to LogFile") \ diagnostic(ccstr, LogFile, NULL, \ "If LogVMOutput or LogCompilation is on, save VM output to " \ product(bool, DisplayVMOutputToStderr, false, \ "If DisplayVMOutput is true, display all VM output to stderr") \ product(bool, DisplayVMOutputToStdout, false, \ "If DisplayVMOutput is true, display all VM output to stdout") \ However, in this case, the code uses: jio_fprintf(defaultStream::error_stream() which should put the output on the error stream that we have specified. Of course, when you take a step back to think about it, the message "Picked up JAVA_TOOL_OPTIONS: ..." is output before we have processed the command line options necessary to change the destination of the error stream. Here's an example to illustrate: $ JAVA_TOOL_OPTIONS="-XX:+PrintCommandLineFlags" java -cp /tmp Hello Picked up JAVA_TOOL_OPTIONS: -XX:+PrintCommandLineFlags -XX:InitialHeapSize=1072524928 -XX:MaxHeapSize=17160398848 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC Hello World! The '-XX:+PrintCommandLineFlags' option above caused the command line options (real and implied) to be printed to stdout. Here's another example to illustrate redirecting VMOutput: $ JAVA_TOOL_OPTIONS="-XX:+PrintCommandLineFlags -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/tmp/Hello.log" java -cp /tmp Hello Picked up JAVA_TOOL_OPTIONS: -XX:+PrintCommandLineFlags -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/tmp/Hello.log Hello World! The output from the '-XX:+PrintCommandLineFlags' option is no longer here, but it is here: $ grep PrintCommandLineFlags /tmp/Hello.log -XX:+PrintCommandLineFlags -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/tmp/Hello.log -XX:-DisplayVMOutput -XX:InitialHeapSize=1072524928 -XX:LogFile=/tmp/Hello.log -XX:+LogVMOutput -XX:MaxHeapSize=17160398848 -XX:+PrintCommandLineFlags -XX:+UnlockDiagnosticVMOptions -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC Note that the "Picked up JAVA_TOOL_OPTIONS:" output shows up for both example java cmds. OK, so one more example: $ JAVA_TOOL_OPTIONS="-XX:+PrintCommandLineFlags" java -XX:+UnlockDiagnosticVMOptions -XX:-DisplayVMOutput -XX:+LogVMOutput -XX:LogFile=/tmp/Hello.log -cp /tmp Hello Picked up JAVA_TOOL_OPTIONS: -XX:+PrintCommandLineFlags Hello World! This time we passed just '-XX:+PrintCommandLineFlags' via JAVA_TOOL_OPTIONS to cause the "Picked up JAVA_TOOL_OPTIONS: ..." output and we put the rest of magic VMOutput options directly on the command line... and it didn't work any better... Surprised? Not really. When we take yet another step back, we have to think about how all options are processed and not just these special ways of getting more options into the VM... Options processing in the VM is basically: - gather/parse options from all the different sources - process the options from left-to-right and finalize them What this means is that while we have parsed the VMOutput options during the gather/parse phase, they have not yet been processed at the point where the "Picked up JAVA_TOOL_OPTIONS: ..." output string is generated. What all this means is that we don't have a way to redirect this message to another place without changing when options take effect during options processing; that would not be a good idea and would risk breaking options processing. So that leaves adding an option to suppress the message. Yes, we could do this, but is it a good idea? The reason that the message is issued is that the feature being used is dangerous and the VM should warn about it. I strongly recommend that we don't try to change this behavior.
03-04-2014