Dmitry,
Beyond Staffan's proposal for jtreg to provide tests with a pointer to
the location of precompiled native code, there are no plans to change
the way jtreg execute tests, processes action tags like @build, @run,
etc.
-- Jon
On 05/01/2014 09:12 AM, Dmitry Samersoff wrote:
Staffan,
Couple of tests require both Java and native code, so compiling it's all
into the single directory might be a problem. Some test used to access
additional data in TESTSRC so we have to copy it as well.
One of possible solution is to allow the tests to support two
independent steps - "build" and "run".
on build side - run all tests with "build" parameter, tests that don't
have build step will just do nothing and continue work as today. Then
bundle entire test tree.
on test side - run all tests with the "run" parameters. Test that have
build step have to copy all required files from build output directory
to work directory.
JDK configuration options could be provided through include file for
make/shell or property file.
It allows the test to achieve whatever build and test behavior it
requires and allows us to move to right direction, without breaking
existing things.
-Dmitry
On 2014-04-25 16:02, Staffan Larsen wrote:
There are a couple of jtreg tests today that depend on native components
(either JNI libraries or executables). These are handled in one of two ways:
1) The binaries are pre-compiled and checked into the repository (often inside
jar files).
2) The test will try to invoke a compiler (gcc, cl, …) when the test is being
run.
Neither of these are very good solutions. #1 makes it hard to run the setup the
test for all platforms and requires binaries in the source control system. #2
is hit-and-miss: the correct compiler may or may not be installed on the test
machine, and the approach requires platform specific logic to be maintained.
I would like to propose that these native components are instead compiled when
the product is built by the same makefile logic as the product. At product
build time we know we have access to the (correct) compilers and we have
excellent support in the makefiles for building on all platforms.
If we build the native test components together with the product, we also have
to take care of distributing the result together with the product when we do
testing across a larger number of machines. We will also need a way to tell the
jtreg tests where these pre-built binaries are located.
I suggest that at the end of a distributed build run, the pre-built test
binaries are packaged in a zip or tar file (just like the product bits) and
stored next to the product bundles. When we run distributed tests, we need to
pick up the product bundle and the test bundle before the testing is started.
To tell the tests where the native code is, I would like to add a flag to jtreg
to point out the path to the binaries. This should cause jtreg to set
java.library.path before invoking a test and also set a test.* property which
can be used by test to find it’s native components.
This kind of setup would make it easier to add and maintain tests that have a
native component. I think this will be especially important as more tests are
written using jtreg in the hotspot repository.
Thoughts on this? Is the general approach ok? There are lots of details to be
figured out, but at this stage I would like to hear feedback on the idea as
such.
Thanks,
/Staffan
