RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests

Ioi Lam ioi.lam at oracle.com
Wed Jan 30 08:19:28 UTC 2019


On 1/29/19 10:15 PM, David Holmes wrote:
> On 30/01/2019 3:55 pm, Ioi Lam wrote:
>>
>> On 1/29/19 8:35 PM, David Holmes wrote:
>>> Hi Ioi,
>>>
>>> On 30/01/2019 1:51 pm, Ioi Lam wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8218029
>>>> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ 
>>>>
>>>>
>>>> Please review this simple fix. For portability,
>>>>
>>>>       "-cp", "\"\"",
>>>>
>>>> in the JVM command-line is replaced with
>>>>
>>>>       "-Djava.class.path="
>>>
>>> Not sure I see how this works. ProcessTools will add:
>>>
>>> -cp <value of java.class.path>
>>>
>>> but you are setting java.class.path to be empty so to me that means 
>>> ProcessTools will set
>>>
>>> -cp
>>>
>>> which is an error? Or does it somehow become
>>>
>>> -cp ""
>>>
>>> ??
>>>
>>> And does that mean the actual command-line ends up with:
>>>
>>> -cp "" -Djava.library.path=
>>>
>>> ?
>>
>>
>> Each CDS test typically consists of 2 processes. The "main" test 
>> would run in the parent process. It will call 
>> ProcessTools.createJavaProcessBuilder to launch a child process.
>>
>>      public static ProcessBuilder createJavaProcessBuilder(...., 
>> String... command) {
>>          ..
>>          args.add("-cp");
>>          args.add(System.getProperty("java.class.path"));
>>          ..
>>          Collections.addAll(args, command);
>>
>> Here, the java.class.path property is from the parent process, so it 
>> won't be empty.
>
> Ah! Yes of course.
>
>> For the tests I touched, the child process's command-line will end up 
>> looking like this
>>
>>         java -cp  <some long jtreg stuff> -Djava.library.path= Foo
>>
>> and the -Djava.library.path= argument overrides the earlier -cp 
>> argument.
>
> s/library/class/ :)
>
>> Does this answer your question?
>
> Yes - thanks. I can't help but think this is working around a problem 
> that should be more readily solvable, but I don't have time to delve 
> into ProcessTools.
>
>> ========
>>
>> BTW, ProcessTools.createJavaProcessBuilder actually is buggy. If the 
>> parent process's java.class.path is indeed empty, on Windows, the 
>> child process will get
>>
>>         java -cp Hello
>>
>> I.e., Windows throws away the empty argument. I could fix it as
>>
>> String cp = System.getProperty("java.class.path");
>> if (cp != null) {
>>      args.add("-cp");
>>      args.add(cp);
>> } else {
>>      args.add("-Djava.library.path=");
>> }
>>
>> What do you think?
>
> I think it sounds like ProcessTools both needs a fix for that and 
> could better handle the "forwarding" of the classpath. Though on the 
> other hand do these tests really need to use createJavaProcessBuilder 
> (which presumably allows you to pass through runtime args from jtreg 
> etc) and just launch the VM under test in a more direct and simple way?


We need to pass the jtreg -vmoptions to the child processes (e.g., 
-Xcomp, GC flags, etc).



>
> David
> -----
>
>> Thanks
>>
>> - Ioi
>>
>>
>>
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> Thanks!
>>>>
>>>> Ioi
>>>>


More information about the hotspot-runtime-dev mailing list