<i18n dev> RFR: JDK-8211161: java.lang.ArithmeticException: divide by zero from java.text.DecimalFormat.format()

[naoto.sato at oracle.com]

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.

Naoto

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 
>> 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