RFR (XS): 8193105: Print error code when map_memory_to_file() fails
sangheon.kim at oracle.com
Wed Dec 6 19:30:37 UTC 2017
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.
>> 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) . 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.
> 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
More information about the hotspot-gc-dev