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

David Holmes david.holmes at oracle.com
Thu Dec 7 01:54:47 UTC 2017


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 !     vmexitduringinitialization(errmsg("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 utilposixfallocate doesn't necessarily return an error code! That's another bug in this particular so-called "posix" function! :( OSX version of utilposixfallocate() 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



More information about the hotspot-gc-dev mailing list