RFR: 7012961 runtime/jni/WindowsExceptionFilter/WindowsExceptionFilter01 crashes on windows-amd64
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Dec 12 08:28:02 PST 2013
On 12/12/13 8:33 AM, Zhengyu Gu wrote:
> Hi Dan,
> I searched mercurial repo and related bugs which dated back jdk5, I
> could not find when it was disabled. The only comment that sheds some
> light, is that in original code:
> 2280 If EXCEPTION_FLT_* happened after some native method modified
> 2281 mxcsr - it is not a jvm fault.
> Did we move arithmetic calculations to intrinsic routines at some point?
Yes. Over time we have added intrinsic versions of various routines
(arithmetic and others) as performance improvements; the Compiler Team
may know of the specific timeline for the various routines...
So what you're saying here is that all the new code that is now
enabled on Win64 is necessary because you now need to handle
EXCEPTION_FLT_* on Win64 where before we only needed to handle
EXCEPTION_FLT_* on Win32.
Do I have this right?
> On 12/12/2013 9:56 AM, Daniel D. Daugherty wrote:
>> A little more explanation about the code that was previously disabled
>> on Win-64 and is now enabled would be helpful. It's difficult to see
>> your reasons for this change based on just the webrev.
>> On 12/11/13 10:52 AM, Zhengyu Gu wrote:
>>> This is another nightly clean up bug, and it is targeted to JDK9.
>>> The comment on original code line 2280 - 2281 is not accurate, since
>>> compiled code and intrinsic routines also can cause EXCEPTION_FLT_*.
>>> This particular testcase actually triggers
>>> EXCEPTION_FLT_DIVIDE_BY_ZERO from intrinsic routine.
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7012961
>>> Webrev: http://cr.openjdk.java.net/~zgu/7012961/webrev.00/
>>> Tested on Windows 64.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev