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

[Erik Joelsson]

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)

In order to fully adopt the new run-test framework, we need to switch 
over the automated and distributed testing system at Oracle to the new 
framework. To get this to work, there are number of issues that needed 
to be fixed. Here follows a brief explanation, see bug for more details.

For RunTest.gmk and related makefiles there are a number of minor tweaks 
to support all the necessary control variables that are currently used 
for the old test makefiles, as well as correcting some test setup settings.

In addition to that, some tests also needed to be modified:

Timeouts
The current default timeoutFactor in the makefiles is 4. However, the 
old Mach5 executor overrides that to 10. I don't think it should dabble 
with such things and leave it to the makefiles, the user, or a specific 
job definition, so with the new run-test executor, it no longer does. 
This means many tests now have a much shorter effective timeout. Because 
of this, we need to increase the timeout on some that are now prone to 
timing out. I have run tier1-5 a few times to try and find these and 
added /timeout=300 (which will result in the same effective timeout as 
before) when specific tests seemed problematic.

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.

/Erik