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

[sangheon.kim]

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.

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