You have pretty much nailed it except that these options are picked up even if you start JVM in-process via a library call.
The fact that _JAVA_OPTIONS is not documented suggests that it is not recommended to use this variable, and I've actually seen people abuse it by setting it in their ~/.bashrc. However, if you want to get to the bottom of this problem, you can check the source of Oracle HotSpot VM (e.g. in OpenJDK7).
You should also remember that there is no guarantee other VMs have or will continue to have support for undocumented variables.
UPDATE 2015-08-04: To save five minutes for folks coming from search engines, _JAVA_OPTIONS trumps command-line arguments, which in turn trump JAVA_TOOL_OPTIONS.
You have pretty much nailed it except that these options are picked up even if you start JVM in-process via a library call.
The fact that _JAVA_OPTIONS is not documented suggests that it is not recommended to use this variable, and I've actually seen people abuse it by setting it in their ~/.bashrc. However, if you want to get to the bottom of this problem, you can check the source of Oracle HotSpot VM (e.g. in OpenJDK7).
You should also remember that there is no guarantee other VMs have or will continue to have support for undocumented variables.
UPDATE 2015-08-04: To save five minutes for folks coming from search engines, _JAVA_OPTIONS trumps command-line arguments, which in turn trump JAVA_TOOL_OPTIONS.
There is one more difference: _JAVA_OPTIONS is Oracle specific. IBM JVM is using IBM_JAVA_OPTIONS instead. This was probably done to be able to define machine-specific options without collisions. JAVA_TOOL_OPTIONS is recognized by all VMs.
java - Difference between JAVA_OPTS and JAVA_TOOL_OPTIONS? - Stack Overflow
Hot Linked Questions - Stack Overflow
JVM env var on Docker: JAVA_TOOL_OPTIONS or JAVA_OPTS?
java - Information about _JAVA_OPTIONS - Stack Overflow
JAVA_TOOL_OPTIONS is read by some JDK tools, but has limited applicability.
JAVA_OPTS is a convention used by Apache Tomcat and some other apps, but is not
read directly by any JDK tools published by Sun/Oracle, AFAIK.
From: https://forums.oracle.com/forums/thread.jspa?messageID=6438415
JAVA_OPTS is not an environment variable that the java executable will recognize on it's own. Instead, various scripts which wrap the start up of java will often use an environment variable named JAVA_OPTS to configure the java executable (for example, the tomcat startup script does this).
see "what is" doc and "tool options" doc
Basically, the JAVA_TOOL_OPTIONS is intended for use by development tools, monitoring tools and the like whereas JAVA_OPTS is used for running 'general' Java programs, I think people tend to mix and match somewhat (from what Google has shown me example wise).
You can use _JAVA_OPTIONS to pass options to any JVM process started on your system.
For example,
set _JAVA_OPTIONS=-Dsun.java2d.noddraw=true
When a JVM starts, it parses the value of _JAVA_OPTIONS as if the parameters were at the command line of java. You can see the passed parameters via JVisualVM.
For more information, read the blog post: What I discovered while trying to pass Default JVM Parameters
And according to https://bugs.openjdk.java.net/browse/JDK-4971166 undocumented Hotspot-specific _JAVA_OPTIONS was superseded by JAVA_TOOL_OPTIONS that is included in standard JVMTI specification, does better handling of quoted spaces and should be always preferred.
Since JDK 9+ there's also JDK_JAVA_OPTIONS as the preferred replacement, see What is the difference between JDK_JAVA_OPTIONS and JAVA_TOOL_OPTIONS when using Java 11?