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