Proposal: jtreg tests with native components

[Staffan Larsen]

On 30 apr 2014, at 11:39, David Holmes <david.holmes at oracle.com> wrote:

> Hi Staffan,
> 
> On 25/04/2014 10:02 PM, 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.
> 
> #2 is far from perfect but ...
> 
>> 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.
> 
> don't under estimate the complexity involved in building then "distributing" the test binaries.

I don’t. It will be complicated, but I’m sure we can do it.

> 
> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses.

Can you explain more? Why can’t I use CFLAGS as it is?

> 
> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites.

I have talked to SQE. I don’t know of any other projects to handle this.

/Staffan


> 
> David
> -----
> 
>> 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
>>