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

[Coleen Phillimore]

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.