RFR (XS): 8193105: Print error code when map_memory_to_file() fails

[David Holmes]

On 7/12/2017 5:30 AM, Sangheon Kim wrote:
> On 2017-12-06 오전 11:19, sangheon.kim wrote:
>> Hi David,
>>
>> Thank you for reviewing this.
>>
>> On 12/06/2017 03:31 AM, David Holmes wrote:
>>> On 6/12/2017 9:25 PM, David Holmes wrote:
>>>> Hi Sangheon,
>>>>
>>>> On 6/12/2017 5:46 PM, sangheon.kim wrote:
>>>>> Hi all,
>>>>>
>>>>> Could I have some reviews for this change?
>>>>>
>>>>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on 
>>>>> Alternative Memory Devices) introduced a new 
>>>>> test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc 
>>>>> with fastdebug build. But unfortunately there's no error print when 
>>>>> related function fails.
>>>>>
>>>>> This proposal is simply adding error code print for further 
>>>>> investigation of JDK-8192871(TestAllocateHeapAt fails), not change 
>>>>> its logic.
>>>>>
>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105
>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0
>>>>> Testing: hs-tier1
>>>>
>>>> !     vm_exit_during_initialization(err_msg("Error in mapping Java 
>>>> heap at the given filesystem directory. error(%d)", ret));
>>>>
>>>> You should use strerror(ret) to print a readable error string here.
>> Done.
>>
>>>
>>> Except you can't because on OSX util_posix_fallocate doesn't 
>>> necessarily return an error code! That's another bug in this 
>>> particular so-called "posix" function! :(
>> OSX version of util_posix_fallocate() uses fcntl(would return 9 kinds 
>> of errors) and ftruncate(12 errors). And both functions set errno when 
>> those functions fail(i.e. return -1) [1]. But when we get a return 
>> value of -1, we don't know which function is failed. If this is your 
>> concern I would prefer to address under different CR as I wanted to 
>> add this log for Sparc ASAP. JDK-8192871 is reported on Sparc so far.
> Sorry, I misunderstood what you said.
> Now I understand that OSX version is not returning the error code. I 
> will file a new bug for this.

Right. But that also means using strerror is not appropriate ... though 
will it actually cause a problem? Let's go with Kim's suggestion and 
just stick with your original version that prints the numeric value. The 
strerror can be added once the other bug is fixed.

Thanks,
David

> Thanks,
> Sangheon
> 
> 
>>
>> FYI, as there are 3 duplicated errors(EACCES, EBADF and EINVAL) 
>> between 2 functions, we can't distinguish in these cases.
>>
>> webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.1
>>
>> [1]:
>> http://www.manpages.info/macosx/fcntl.2.html
>> http://www.manpages.info/macosx/ftruncate.2.html
>>
>> Thanks,
>> Sangheon
>>
>>
>>>
>>> David
>>>
>>>> Thanks,
>>>> David
>>>>
>>>>> Thanks,
>>>>> Sangheon
>>
>