RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero from java.text.DecimalFormat.format()
enasser at in.ibm.com
Thu Sep 27 05:42:07 UTC 2018
Hi Joe, Naoto,
Thank you for your review comments. I agree with you that as per the VM
specification, divide-by-zero in DecimalFormat is allowed and hence the
current fix is more of a good to have rather than a defect fix. As Joe
suggested, I will see whether the new fix give better performance in any
I think the current bug description may not be directly applicable to
hotspot and a new bug explaining the behavior difference between before
and after create JVM while handing SIGFPE may be better.
From: naoto.sato at oracle.com
To: joe darcy <joe.darcy at oracle.com>, Nasser Ebrahim
<enasser at in.ibm.com>, core-libs-dev Libs <core-libs-dev at openjdk.java.net>,
"i18n-dev at openjdk.java.net" <i18n-dev at openjdk.java.net>
Date: 09/27/2018 01:55 AM
Subject: Re: RFR: JDK-8211161: java.lang.ArithmeticException:
divide by zero from java.text.DecimalFormat.format()
Hi, Nasser, Joe,
I agree with Joe as to the assessment on DecimalFormat code. The
existing code looks correct. Unless there is any obvious need to replace
the piece with bit operation, I'd just leave it as is. The jira issue
can be transferred to HotSpot, though.
On 9/26/18 11:14 AM, joe darcy wrote:
> Hi Nasser,
> On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
>> Hi Joe,
>> Thank you for your review comments.
>> I agree with you that the specification says that "The floating-point
>> operations of the Java Virtual Machine do not throw exceptions, trap,
>> or otherwise signal the IEEE 754 exceptional conditions of invalid
>> operation, division by zero, overflow, underflow, or inexact." as per
>> the JVM specification
>> I noticed that the SIGFPE is consumed and no exception is thrown when
>> SIGFPE is enabled before create JVM. Hence, there is an inconsistency
>> in the hotspot behavior when the SIGFPE is enabled before and after
>> create JVM. If the trap is enabled before create JVM, it just catch
>> the exception and continue where as if the trap is enabled after
>> create JVM, then it result in the ArithmeticException.Hence, the JVM
>> behavior needs to be fixed to make the behavior consistent.
>> Still, I feel it makes more sense to check the sign bit to decide a
>> number is negative or positive rather than divide-by-zro to make
>> infinity and compare with zero. If you agree with my view, a separate
>> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we
>> can change the component of this bug. Please comment.
> Here is my rephrasing of the situation:
> If someone deliberately misconfigures a CPU such that its floating-point
> behavior does not conform to the JVM specification, Java library code
> throws unexpected exceptions.
> In that case, it is not a bug in the library code, it is a problem
> stemming from the deliberate CPU misconfiguration.
> One could make a case that the new code is better in some way, perhaps
> faster on some platforms, but it is functionally correct as is and
> should not be described otherwise. The i18n team can weigh in with their
> assessment of the proposed patch from a maintenance perspective.
> The HotSpot team could evaluate if the VM implementation should be
> further hardened against hostile changes to the FPU control word(s), but
> I would be content if this issue were closed as not a bug.
More information about the core-libs-dev