Proposal: jtreg tests with native components

[Christian Tornqvist]

Hi Staffan,

This sounds like a great proposal that would solve many of our issues with
tests requiring native code. Would it be possible for the make system to
pick up a custom makefile from a test folder? The use cases I see are: 

1. Launcher type tests (we have a few of these), these needs to be compiled
into an executable 
2. Test libraries that might depend on being compiled with certain
compiler/linker flags (don't think we have tests like this today though).

Thanks for working on this :)

Thanks,
Christian

-----Original Message-----
From: jtreg-dev [mailto:jtreg-dev-bounces at openjdk.java.net] On Behalf Of
Staffan Larsen
Sent: Friday, April 25, 2014 8:03 AM
To: build-dev at openjdk.java.net build-dev; jtreg-dev at openjdk.java.net
Subject: Proposal: jtreg tests with native components

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