Take 2: RFR: 8197429: Increased stack guard causes segfaults on x86-32

[Leonid Mesnik]

Hi Andrew

> On Feb 14, 2018, at 1:23 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 13/02/18 23:44, Leonid Mesnik wrote:
> 
>> Thank you for fixing tests. I think that it would be also better to
>> rewrite test in java using process utilities
>> test/lib/jdk/test/lib/process/ProcessTools.java.
>> It is possible to push shell test but the general direction for
>> OpenJDK tests is to use java and testlibrary.
>> Now it is more easier to develop and debug tests with new processes
>> using testlibrary. Also the could be execute faster.
>> But if you have any reasons to keep test in shell that I am fine.
> 
> I'm trying to test a very specific fault path, one that is due to the
> JNI launcher from C.  IfI wanted to test something else I would do
> something else, but I don't understand your motivation for wanting to
> write the test in some other way.
There several benefits from writing tests in java 
1) Test filtering and more correct results.
It is possible to filtering using requires tag:
* @requires (os.family == "linux”)
So jtreg will filter this test instead of running it and “pass” on non-linux platforms. 
It helps to have more precise test results 
2) More effective execution.
For each shell test it is required to run separate shell process and then at least run and parse java -version in test_env.sh.
While java-based tests which use @driver are compiled and executed in the same vm. So only single new process is forked for your test.

I wouldn’t insist on writing this test in java right now but eventually we are going to port all shell tests in java anyway.

Leonid

> 
> -- 
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671