Review Request JDK-8136930 Examine implications for custom launchers, equivalent of java -X options in particular

[Alan Bateman]

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.