RFR(s): 8143291: Remove redundant coding around os::exception_name (original) (raw)
David Holmes david.holmes at oracle.com
Thu Nov 19 11:56:07 UTC 2015
- Previous message: RFR(s): 8143291: Remove redundant coding around os::exception_name
- Next message: RFR(s): 8143291: Remove redundant coding around os::exception_name
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Thomas,
I like the idea of this, but it will take me a little time to check all the details. More below ...
On 19/11/2015 8:23 PM, Thomas Stüfe wrote:
Hi,
please take a look at this change. bug: https://bugs.openjdk.java.net/browse/JDK-8143291 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8143291/webrev.00/webrev/ This fix does some cleanups around os::exceptionname(). - os::exceptionname() is identical on all Posix platforms (it returns a signal name string for a signal number), so it can be merged into osposix.cpp - There is no need for a platform-specific implementation, as we have already os::Posix::getsignalname(). Use that instead of platform-specific solutions. - I added a function os::Posix::getsignalnumber() which is the inverse of os::Posix::getsignalname(). - Before, a signal-to-number table was kept in jvm.cpp. That was used to implement os::exceptionname() and also for JVMFindSignal -> on AIX, I removed the coding altogether and used os::Posix::getsignalnumber() as a base for JVMFindSignal. -> on the other Unices, I did not feel so confident, because strictly spoken we may change the behaviour slightly to before: os::Posix::getsignalname() knows more signal names than the platform specific tables knew before, so now Signal.findSignal("") would return more matches than before.
How so? If the additional names are platform specific then they won't exist at build time on the other platforms and so will be elided from the table.
BTW the existing Solaris code is incorrect when we start building on Solaris 11, so it would be good to use something that uses the actual build time signal value rather than the current array based approach.
Thanks, David
I am not sure whether I am overcautious here - should I treat the other Unices the same way I treated AIX, i.e. implement Signal.findSignal("") -> JVMFindSignal via os::Posix::getsignalnumber()? This would further simplify the coding.
Oh, this fix also fixes an issue where os::exceptionname() would return NULL for an unknown signal number, but no caller ever checks for NULL before printing the result. The new os::exceptionname() always returns a string and also distinguishes between "unknown but valid signal" and "invalid signal". Kind Regards, Thomas
- Previous message: RFR(s): 8143291: Remove redundant coding around os::exception_name
- Next message: RFR(s): 8143291: Remove redundant coding around os::exception_name
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]