RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero from java.text.DecimalFormat.format()
joe darcy
joe.darcy at oracle.com
Wed Sep 26 18:14:12 UTC 2018
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
> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1.
>
> 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.
Cheers,
-Joe
More information about the core-libs-dev
mailing list