RFR: JDK-8072842 Add support for building native JTReg tests

[Magnus Ihse Bursie]

On 2015-02-11 02:35, David Holmes wrote:
> Hi Magnus,
>
> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote:
>> Here is an addition to the build system, that will compile native
>> libraries and executables and make them available for JTReg tests
>> written in Java.
>
> Sorry I'm missing the basics here: when does this compilation take 
> place? As part of a normal build? Where will the build artifacts go?

This is the first application of the new test-image/product-images 
separation we discussed previously. :)

These tests are built as part of the "test-image" target. (Actually, 
they are built by individual rules like build-test-jdk-jtreg-native, and 
the relevant parts are put into the test image by 
test-image-jdk-jtreg-native, which test-image depends on.)

The test-image target, as we discussed earlier, are built as part of 
"all" or "all-images", but not the old "images" or "jdk" targets. Also, 
the "test" target depends on "test-image", so you can actually start off 
a complete build by specifying just what tests you want to run. ("test 
driven" from a makefile point of view :-))

The build artifacts go into the new test image, in 
build/$BUILD/images/test, which hitherto has only contained a 
placeholder. For Oracle engineers: This test image is built by default 
by JPRT, and some of the changes in jprt.properties allow JPRT to know 
to depend on that test image to run tests.

/Magnus

>
> Thanks,
> David H.
>
>> This patch is the result of the work (in serial, mostly) of Staffan
>> Larsen, David Simms and me. (And possible more that I don't know about.)
>>
>> In it current form, the patch only provides the framework on which to
>> attach real tests. To prove the concept, some initial dummy tests are
>> present. These are supposed to be removed as soon as real tests starts
>> to propagate into the jdk and hotspot jtreg test suites.
>>
>> The behavior is based on the following design: For directories with
>> native jtreg compilation enabled, the build system searches for native
>> files prefixed with either "lib" or "exe", and compiles a free-standing
>> library or an executable, respectively, for each such file. Since all
>> compiled files are placed in a single directory (this is currently a
>> requirement from the jtreg native support), there is the additional
>> requirement that all files have unique names.
>>
>> My personal opinion is that a better long-term approach is to compile
>> all tests into a single library, if possible. (I realize some tests need
>> to be separate to test library loading, etc.) For that to work, however,
>> JTReg needs to be changed. The build framework in the patch is designed
>> in such a way that it will be easy to add compilation to a common
>> library in the future, if that restriction is lifted from JTReg.
>>
>> This patch also lays the foundation for building additional tests, not
>> only native jtreg tests, by the build system in the future. For
>> instance, it codifies the suggested correspondence between make targets,
>> intermediate test output and test image final build results. With the
>> on-going test co-location project, we expect a stream of tests to be
>> added to the build system in the future, and we hope this project can
>> serve as an example of a suitable way of integration.
>>
>> The patch modifies hotspot code, but it's mostly due to the addition of
>> the new dummy tests. My preference would be to integrate this patch via
>> jdk9-dev, since it modifies the build system most of all, but I'm open
>> for discussion.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 
>>
>>
>>
>> /Magnus