RFR: JDK-8212028: Use run-test makefile framework for testing in Oracle's Mach5

[Erik Joelsson]

On 2018-10-12 01:37, Magnus Ihse Bursie wrote:
> Hi Erik,
>
> Thank you for preserving through this, so we finally can move to 100% 
> run-test!
>
> On 2018-10-12 00:29, Erik Joelsson wrote:
>
>> Hello,
>>
>> (adding serviceability-dev and hotspot-dev for test changes)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8212028
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~erikj/8212028/webrev.01/index.html (From 
>> ihse-runtestprebuilt-branch in jdk-sandbox)
> Build changes look good. And I agree with the solution to add longer 
> timeout to individual tests.
Thanks!
>>
>> test/hotspot/jtreg/runtime/appcds/jvmti/InstrumentationTest.java
>> This test spawns a child process and tries to locate it using the 
>> attach api, by looking for a unique token in the command line string 
>> of the spawned JVM. The problem is that the command line string it 
>> gets from the attach api is truncated and the token is last on the 
>> command line. This normally works well, but the arguments before it 
>> are 3 files, with full absolute paths inside the jtreg work 
>> directory. With Mach5 we have pretty deep work directories, and with 
>> run-test, we make them even deeper. This unfortunately trips the 
>> limit and the test fails. I have fixed this by reordering the 
>> arguments to the child process.
> ... but I'm not sure I understand this. Is it a command-line length 
> we're hitting? If so, how can reordering the arguments solve anything? 
> I understand why this can preserve the token, but will not one of the 
> paths be cut of instead?
>
I will try to be clearer. The command line is fine for running the child 
process. The truncation happens when the attach api is used to try to 
find the child process. It basically calls something that lists all JVMs 
on system, iterates through them and looks at the "description" field. 
This field happens to contain the first X characters of the command line 
so the test looks for the unique token it knows it put there. (I don't 
know the exact value of X, but could find out). Until now, X was big 
enough to fit the whole command line, but with the 3 absolute path files 
in there now growing long enough, the last argument is pushed out of the 
description field. This means the test process is unable to locate the 
child process in the list of JVMs. What then happens is the test keeps 
on looking, taking new snapshots of all JVMs on the system until the 
test finally times out. By reordering the arguments, the token is less 
likely to be cut out of the description field.

/Erik