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