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
