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

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Tue Feb 10 14:23:41 UTC 2015

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.

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


More information about the hotspot-dev mailing list