RFR: 8224974: Implement JEP 352

[Dmitry Chuyko]

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