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

[Magnus Ihse Bursie]

> 12 okt. 2018 kl. 18:16 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> 
>> 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.
> 

I see. Then your fix makes totally sense. 

/Magnus

> /Erik
>