On 6/10/16 4:21 PM, Alan Bateman wrote:
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.
I agree -Xpatch needs to be in the vm. It is used by the vm.
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.
Changing the conventions for a couple things but not all does not
simplify anything. And you're not really changing the communication
between the world and the jdk. They're still properties.
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.
True.
On the syntax/semantics of these options then JEP 261 has all the
details. Yes, a lot to take in at once.
Yeah, there's a lot here.
Coleen
-Alan.
