RFR: 8224974: Implement JEP 352

[Dmitry Chuyko]

The test fails on some machines but does not fail on others, all 4.x 
kernels. The possible problem may be when build host and run host are 
different machines. This seems to be related to map0() implementation in 
FileChannelImpl.c in case MAP_SYNC and MAP_SHARED_VALIDATE are not 
defined (or defined).

I also recommend to print original ioe stacktrace in the test. Adding 
such gives us useful information like this:

java.io.IOException: Invalid argument

at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062)
at MapFail.main(MapFail.java:48)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)
java.lang.Exception: unexpected message for IOExceptionInvalid argument
at MapFail.main(MapFail.java:61)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:830)
Caused by: java.io.IOException: Invalid argument
at java.base/sun.nio.ch.FileChannelImpl.map0(Native Method)
at java.base/sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:1062)
at MapFail.main(MapFail.java:48)
... 6 more

-Dmitry

On 8/7/19 3:04 PM, Dmitry Chuyko wrote:
> On 8/7/19 2:02 PM, Dmitry Chuyko wrote:
>> Andrew,
>>
>> New code is buildable and new MapFail test passes on different 
>> platforms except it fails on linux i386:
>
> Ah, that even was x86_64 (sorry, mixed up results from automated 
> system). I'll try to reproduce it by hand to see if there are any 
> additional details.
>
> -Dmitry
>
>>
>> ----------System.err:(12/712)----------
>> java.lang.Exception: unexpected message for IOExceptionInvalid argument
>>     at MapFail.main(MapFail.java:60)
>>     at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
>> Method)
>>     at 
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>     at 
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>>     at 
>> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:246)
>>     at java.base/java.lang.Thread.run(Thread.java:830)
>>
>> First there is a problem with the test,
>> and a minor test issue is it would be good to add ": " before actual 
>> unexpected message.
>>
>> -Dmitry
>>
>> On 8/7/19 12:31 PM, Dmitry Chuyko wrote:
>>> On 8/6/19 6:58 PM, Andrew Dinn wrote:
>>>> ......................
>>>> No this behaviour is not currently tested. However, the only client at
>>>> present will never exercise that path so it is not critical to test it
>>>> now. I'd be happy to address testing of this behaviour as part of a
>>>> follow-up JIRA issue if you would be so good as to raise it. I say 
>>>> that
>>>> because I would very much like to get this functionality into a 
>>>> release
>>>> to simplify more extensive testing by Red Hat's middleware teams.
>>> It sounds reasonable, I'll create a tiny RFE after you push the JEP.
>>>>
>>>>> New MapFail test succeeds if proper IOException or any
>>>>> UnsupportedOperationException was caught but it aren't those 
>>>>> situations
>>>>> actually 2 different ones that require distinct checks? If you say 
>>>>> that
>>>>> is the situation when results depend on Linux version, it makes 
>>>>> sense at
>>>>> least to put a comment in the test because it's really not trivial.
>>>> The documentation of the API under test makes it clear that both 
>>>> errors
>>>> can occur and under what circumstances. However, a note in the test 
>>>> will
>>>> certainly do no harm. I will insert one before checking in the patch.
>>>>
>>>>> Can PmemTest check IOException with message "map with mode MAP_SYNC
>>>>> unsupported" as a part of expected behavior, not just showing a test
>>>>> failure?
>>>> I don't see any need for this now that MapFail has been provided. Wit
>>>> that alterative in place for checking map failures on non-DAX file
>>>> syetems PmemTest is now primarily intended to test behaviour with a 
>>>> DAX
>>>> file system which it expects to have been set up in advance as 
>>>> described
>>>> in the main comment. So, the scenario you describe is not really an
>>>> intended usage and I woudl argue that a failure is the right way to
>>>> signal that.
>>>
>>> OK, finally got it, thank you.
>>>
>>> -Dmitry
>>>
>>>>
>>>> regards,
>>>>
>>>>
>>>> Andrew Dinn
>>>> -----------
>>>> Senior Principal Software Engineer
>>>> Red Hat UK Ltd
>>>> Registered in England and Wales under Company Registration No. 
>>>> 03798903
>>>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander