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

[David Holmes]

On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote:
> 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.)

Okay so if I just cd into hotspot/test and use the Makefile to try and 
run some jtreg tests it looks to me that it will define an invalid 
-nativepath

David
-----

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