Running native code test (original) (raw)

Carsten Varming varming at gmail.com
Thu Dec 3 17:13:16 UTC 2015

Dear David,

I think I finally understand what is going on now. :)

The command "make build-test-hotspot-jtreg-native" populates $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ with ".so" files using sub-directories of $(OUTPUTDIR)/support/test/hotspot/jtreg/native/support/ as scratch space for each test.

The command "make test-image-hotspot-jtreg-native" (which I didn't run in my sequence of commands above) copies all files in $(OUTPUTDIR)/support/test/hotspot/jtreg/native/lib/ to $(OUTPUTDIR)/images/test/hotspot/jtreg/native/ . Notice the lacking "/lib" in the target.

Jtreg is passed the parameter "-nativepath:$(TESTNATIVE_DIR)/hotspot/jtreg/native". Jtreg then use the native path to set both system properties: test.nativepath and java.library.path.

This leaves a lot to be desired. Jtreg expects all library files and executables to be in the same directory (there are no executables in the hotspot tests, but the jdk contains one). There is separation between libraries and executables everywhere except in $(OUTPUTDIR)/images/test/{hotspot,jdk}/jtreg/native/ because jtreg and jdk/test/native_sanity/simplenativelauncher/ProgramTest.java expect executables to be in the same directory as libraries. I have never seen that before. Notice that this makes the step copying the executables into the images sub-directory mandatory.

The right thing seems to be to fix jtreg to maintain separation. Something as simple as setting java.library.path to test.nativepath + "/lib" and force a standard layout with bin and lib sub-directories would be an improvement. Perhaps even extend jtreg it to allow separation between libraries and executables from different tests (test A should not have access to libraries from test B).

I will drop this issue now that I have a way to execute tests containing native code, but it would be nice if someone working on jtreg would make it possible keep executables separate from libraries.

Carsten

On Thu, Dec 3, 2015 at 2:15 AM, David Holmes <david.holmes at oracle.com> wrote:

cc'ing build-dev

On 2/12/2015 1:28 AM, Carsten Varming wrote:

Dear David,

See inline. On Tue, Dec 1, 2015 at 2:26 AM, David Holmes <david.holmes at oracle.com_ _<mailto:david.holmes at oracle.com>> wrote: Hi Carsten, On 1/12/2015 8:21 AM, Carsten Varming wrote: Dear Ioi, Absolutely, diff -r 7606b8556225 test/Makefile --- a/test/Makefile Thu Nov 26 13:13:03 2015 +0100 +++ b/test/Makefile Mon Nov 30 17:20:30 2015 -0500 @@ -156,7 +156,7 @@ TESTNATIVEDIR = $(JPRTTESTNATIVEPATH) endif ifdef TESTNATIVEDIR - JTREGNATIVEPATH = -nativepath:$(shell $(GETMIXEDPATH) "$(TESTNATIVEDIR)/hotspot/jtreg/native") + JTREGNATIVEPATH = -nativepath:$(shell $(GETMIXEDPATH) "$(TESTNATIVEDIR)/hotspot/jtreg/native/lib") endif

In hotspot/make/test/JtregNative.gmk we have: BUILDHOTSPOTJTREGOUTPUTDIR := $(BUILDOUTPUT)/support/test/hotspot/jtreg/native The SetupTestFilesCompilation macro adds the subdirectory "lib" to the path such that the ".so" files (or ".dylib" files) end up in $(BUILDOUTPUT)/support/test/hotspot/jtreg/native/lib. Thanks for that. Tracing through these makefile macros is far too painful. I wish there were some way to see what they looked like once expanded. so the above patch should not be needed. Without the patch the following sequence of commands fails: sh configure --enable-debug make images make build-test-hotspot-jtreg-native cd hotspot/test make TESTDIRS=runtime/SameObject TESTNATIVEDIR=../../build/macosx-x8664-normal-server-fastdebug/support/test JTHOME=/Users/cvarming/workspace/jtreg/jtreg JAVAHOME=../../build/macosx-x8664-normal-server-fastdebug/images/jdk PRODUCTHOME=$JAVAHOME jtregtests TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.UnsatisfiedLinkError: no SameObject in java.library.path and java.library.path is defined by: -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x8664-normal-server-fastdebug/support/test/hotspot/jtreg/native What I see in a JPRT build is simply: (cd /scratch/hotspot/make/test && make -r -R -I /scratch/make/common SPEC=/scratch/build/linux-x86-normal-clientANDserver-fastdebug/spec.gmk _MAKELOGFLAGS="" LOGLEVEL=debug -f JtregNative.gmk _ test-image-hotspot-jtreg-native) On the other hand, with the patch the test runs fine. Looking at SameObject.jtr I can see: -Djava.library.path=/Users/cvarming/workspace/jdk9-rt/hotspot/test/../../build/macosx-x8664-normal-server-fastdebug/support/test/hotspot/jtreg/native/lib, i.e., "/lib" is appended to the path and the test pass. So I wonder, are these tests run by JPRT? And if they are, then what I am doing wrong? Yes they are run (or some subset thereof). The -nativepath that gets passed to jtreg does not include a lib component. I'm afraid I don't know what is going wrong. David ----- BTW. This paths above are taken from runs on my mac. The problem also occurs on my Linux desktop. Carsten David -----

# Expect JPRT to set JPRTARCHIVEBUNDLE (path to zip bundle for results) Carsten On Mon, Nov 30, 2015 at 5:17 PM, Ioi Lam <ioi.lam at oracle.com_ _<mailto:ioi.lam at oracle.com>> wrote: Your patch seems to have been stripped by the mailer. Is it possible to just include it as plain text in the e-mail? Thanks - Ioi On 11/30/15 1:34 PM, Carsten Varming wrote: Hi everyone, I was recently trying to run some tests that use native code, e.g., hotspot/runtime/SameObject/SameObject.java and found that I had to apply the attached diff to get the tests to work. I am doing something wrong or is this a trivial bug? Carsten

More information about the build-dev mailing list