Running native code test

Thu Dec 3 17:42:43 UTC 2015

Carsten,

I'll file a RFE for jtreg for you.

-- Jon

On 12/03/2015 09:13 AM, Carsten Varming wrote:
> 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 @@
>>>               TESTNATIVE_DIR = $(JPRT_TESTNATIVE_PATH)
>>>             endif
>>>             ifdef TESTNATIVE_DIR
>>>          -  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>          "$(TESTNATIVE_DIR)/hotspot/jtreg/native")
>>>          +  JTREG_NATIVE_PATH = -nativepath:$(shell $(GETMIXEDPATH)
>>>          "$(TESTNATIVE_DIR)/hotspot/jtreg/native/lib")
>>>             endif
>>>
>>>
>>>      In hotspot/make/test/JtregNative.gmk we have:
>>>
>>>      BUILD_HOTSPOT_JTREG_OUTPUT_DIR :=
>>>      $(BUILD_OUTPUT)/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
>>> $(BUILD_OUTPUT)/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
>>>
>>> TESTNATIVE_DIR=../../build/macosx-x86_64-normal-server-fastdebug/support/test
>>> JT_HOME=/Users/cvarming/workspace/jtreg/jtreg
>>> JAVA_HOME=../../build/macosx-x86_64-normal-server-fastdebug/images/jdk
>>> PRODUCT_HOME=$JAVA_HOME jtreg_tests
>>>
>>> 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-x86_64-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
>> MAKE_LOG_FLAGS="" LOG_LEVEL=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-x86_64-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 JPRT_ARCHIVE_BUNDLE (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
>>>
>>>
>>>
>>>
>>>