Hide
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
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.
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.