On 10/06/2016 19:25, Coleen Phillimore wrote:
:
Yes, I agree, it was the right choice to keep most of the
implementation in the jdk libraries and only expose the jvm to what it
needs to know. The JVM doesn't need to know these options. I assume
that the JDK passes this information to the JVM in some other way.
Ie. the JVM doesn't set any values global or otherwise based on these
options.
-Xpatch has to processed very early (before any classes are loaded). The
other module options are also processed very early in the startup but by
java code that configures the VM rather than by code in libjvm. If you
run with -Xlog:modules=debug then you'll see the initialization.
From what I gather, system properties are the way things are done for
all sorts of jdk parameterization. If you have a comprehensive plan
to move *everything* away from this model, the design should be
reviewed. Having options parsed in hotspot to set system properties
doesn't seem like the design we really want though, unless there's
some better syntax for it.
System properties have been historically used to communicate the value
of options but it doesn't have to be this way and we'd like to get away
from that over time. We can't of course change existing properties (like
java.class.path) for example.
I think the (second) pass should include moving these options back to
the launcher where they belong. The syntax and semantics of these
options is pretty baffling also.
The java launcher is not involved when you use the JNI invocation API.
On the syntax/semantics of these options then JEP 261 has all the
details. Yes, a lot to take in at once.
-Alan.
