Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8039152

Need a way to suppress message when picking up JAVA_TOOL_OPTIONS

    Details

    • Type: Enhancement
    • Status: Closed
    • Priority: P4
    • Resolution: Won't Fix
    • Affects Version/s: 9
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
      None

      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.

        Issue Links

          Activity

          Hide
          dcubed Daniel Daugherty added a comment - - edited
          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.
          Show
          dcubed Daniel Daugherty added a comment - - edited 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.
          Hide
          dcubed Daniel Daugherty added a comment -
          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.
          Show
          dcubed Daniel Daugherty added a comment - 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.
          Hide
          dcubed Daniel Daugherty added a comment -
          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
          Show
          dcubed Daniel Daugherty added a comment - 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
          Hide
          igerasim Ivan Gerasimov added a comment -
          This will not be implemented, as it may introduce a vulnerability
          Show
          igerasim Ivan Gerasimov added a comment - This will not be implemented, as it may introduce a vulnerability

            People

            • Assignee:
              igerasim Ivan Gerasimov
              Reporter:
              igerasim Ivan Gerasimov
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: