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

harold seigel harold.seigel at oracle.com
Tue Jun 7 18:20:59 UTC 2016


Hi,

Please review this updated webrev of the VM changes for JDK-8136930:

    http://cr.openjdk.java.net/~hseigel/bug_8136930.02/

The updated webrev contains improvements suggested by David, Mandy, and 
Lois.

Thanks, Harold

On 6/5/2016 8:50 PM, David Holmes wrote:
> Hi Mandy,
>
> On 4/06/2016 4:47 PM, Mandy Chung wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8136930/webrev.00/
>>
>> -modulepath, -addmods, -limitmods, -XaddExports, -XaddReads, -Xpatch 
>> are java launcher options in the current implementation.  Custom 
>> launchers will have to use -D to set some system properties to 
>> configure module system.  Different ways to configure module system 
>> is confusing and not friendly for environments using both java 
>> launcher and custom launchers.
>>
>> This patch pushes the handling of the module options into the VM.  
>> That will avoid the confusion between launcher and VM options and 
>> avoids needing to use system properties.  All launcher 
>> implementations can configure the module system via JNI Invocation 
>> API setting these options in a unified way.  The options and syntax 
>> remain the same as specified in JEP 261.
>>
>> For the non-repeating options, like the other VM options, the last 
>> one wins.  The current implementation communicates the options to the 
>> module system through system properties, as a private interface, and 
>> these system properties will be removed once they are read during the 
>> module system initialization. These system properties are reserved as 
>> private interface and they will be ignored if they are set via -D in 
>> the command line. Harold implements the hotspot change and can 
>> explain further details.
>>
>> This patch will impact existing tests and scripts that set the system 
>> properties for example to break encapsulation in the command line 
>> e.g. -Djdk.launcher.addexports.<N>.  They will need to be updated to 
>> replace the use of -D with the appropriate module option e.g. 
>> -XaddExports.  Since they are new options in JDK 9, use 
>> -XX:+IgnoreUnrecognizedVMOptions if they need to be ignored by 
>> earlier releases.
>
> Taking an initial look at the VM changes ...
>
> I may be missing the full context but you seem to be checking only 
> that some prefix matches the expected property format, not that the 
> entire value is valid eg. if passed jdk.module.patch.1junk it will match
>
> You use NEW_C_HEAP_ARRAY in places but that will abort the VM on 
> failure, whereas you return error codes for other failure modes. For 
> consistency use NEW_C_HEAP_ARRAY_RETURN_NULL and return an error on 
> NULL. (This seems a pre-existing flaw.)
>
> There seem to be far too many string literals for the various 
> jdk.module.* forms and lots of hard-coded string lengths. It would be 
> nice if that could be cleaned up using #defines, or string constant 
> variables, so that all the potential property names can be located in 
> one place.
>
> Are there any tests in hotspot/test/* that will require changes for this?
>
> Thanks,
> David
>
>> Mandy
>>
>>



More information about the hotspot-runtime-dev mailing list