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.hol...@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.hol...@oracle.com
<mailto:david.hol...@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....@oracle.com
<mailto:ioi....@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
