Proposal: jtreg tests with native components

[Erik Joelsson]

On 2014-05-02 08:53, Staffan Larsen wrote:
> On 1 maj 2014, at 07:45, David Holmes <david.holmes at oracle.com> wrote:
>
>> On 30/04/2014 9:39 PM, Staffan Larsen wrote:
>> The question is whether it is worth it relative to the size of the 
>> problem. 
> I think we will see a large influx of these kinds of tests, especially in the hotspot repo.
I don't doubt it will be worth it.
>>>> You will still need to maintain platform specific logic as you won't necessarily be able to use the CFLAGS etc that the main build process uses.
>>> Can you explain more? Why can’t I use CFLAGS as it is?
>> You _may_ be able to, you may not. I know we already had issues where the CFLAGS as being used for the JDK sources also got applied to building the code-generator utility programs and that didn't work correctly. Here's sample CFLAGS from a JDK build
>>
>> CFLAGS_JDKLIB:=  -W -Wall -Wno-unused -Wno-parentheses       -pipe  -D_GNU_SOURCE -D_REENTRANT -D_LARGEFILE64_SOURCE -fno-omit-frame-pointer  -D_LITTLE_ENDIAN -DLINUX -DNDEBUG -DARCH='"i586"' -Di586 -DRELEASE='"$(RELEASE)"' -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include -I/export/users/dh198349/ejdk8u-dev/build/b13/linux-i586-ea/jdk/include/linux       -I/export/users/dh198349/jdk8u-dev/jdk/src/share/javavm/export     -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/javavm/export     -I/export/users/dh198349/jdk8u-dev/jdk/src/share/native/common   -I/export/users/dh198349/jdk8u-dev/jdk/src/solaris/native/common -m32  -fno-strict-aliasing -fPIC
>>
>> Does that make sense for compiling a test? Does it depend on whether we are building a native library or a native executable?
> I think they make sense, at least initially. If not, we can tune them, but that "tuning” will be in one central location and not spread out in a lot of shell scripts. I also plan to allow individual tests to override the flags if necessary (for example to link with X11).
>
> For executables there is CFLAGS_JDKEXE.
For the initial proof of concept, just using the existing CFLAGS_JDKLIB 
and CFLAGS_JDKEXE will be fine. Going forward, I would like to see 
CFLAGS_TESTLIB and CFLAGS_TESTEXE being provided by configure. There 
will certainly be a lot of common things for both product and test libs 
and as pointed out above, some differences too. We should leverage the 
logic already present in our configure script to provide suitable defaults.

/Erik
> Thanks,
> /Staffan
>
>>>> Also talk to SQE as I'm pretty sure there is an existing project to look at how to better handle this, at least for the internal test suites.
>>> I have talked to SQE. I don’t know of any other projects to handle this.
>> :) It wasn't SQE, it was your project as referenced in a few bug reports last August/September.
>>
>> David
>>
>>
>>> /Staffan
>>>
>>>
>>>> David
>>>> -----
>>>>
>>>>> I suggest that at the end of a distributed build run, the pre-built test binaries are packaged in a zip or tar file (just like the product bits) and stored next to the product bundles. When we run distributed tests, we need to pick up the product bundle and the test bundle before the testing is started.
>>>>>
>>>>> To tell the tests where the native code is, I would like to add a flag to jtreg to point out the path to the binaries. This should cause jtreg to set java.library.path before invoking a test and also set a test.* property which can be used by test to find it’s native components.
>>>>>
>>>>> This kind of setup would make it easier to add and maintain tests that have a native component. I think this will be especially important as more tests are written using jtreg in the hotspot repository.
>>>>>
>>>>> Thoughts on this? Is the general approach ok? There are lots of details to be figured out, but at this stage I would like to hear feedback on the idea as such.
>>>>>
>>>>> Thanks,
>>>>> /Staffan
>>>>>