> On 10 feb 2015, at 15:23, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > 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. > > 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.
To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg. /Staffan > > 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
