Path: csiph.com!x330-a1.tempe.blueboxinc.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 12 May 2011 20:00:51 -0500
Date: Thu, 12 May 2011 18:00:41 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: Java puzzler
References: <4db69c13-878f-4806-adb2-a3c5adb1c48c@glegroupsg2000goo.googlegroups.com> <qrGdnWE1mOKFHVfQnZ2dnUVZ_uKdnZ2d@earthlink.com> <alpine.DEB.2.00.1105112141410.27211@urchin.earth.li> <I6SdnROEzeMni1bQnZ2dnUVZ_sKdnZ2d@earthlink.com> <alpine.DEB.2.00.1105122029030.7602@urchin.earth.li> <-8mdnSRPEIdA21HQnZ2dnUVZ_j2dnZ2d@earthlink.com> <iqhhim$blg$4@speranza.aioe.org> <iqhjks$798$1@dont-email.me> <iqhv2p$at3$1@speranza.aioe.org>
In-Reply-To: <iqhv2p$at3$1@speranza.aioe.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <u_adndVeLeVeH1HQnZ2dnUVZ_qadnZ2d@earthlink.com>
Lines: 28
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 75.8.126.96
X-Trace: sv3-apqdlFq4wmszuY6oOF5zIN4CkYoOxHZpkvvlBbzj3NTXKFtAiTRoxF3Ns/zxIfIoCn8a3Weubcl7goY!XyJAtuMXHBPsNfo4EcwbTfzMzN8X7EoaRab6cD9Mg4Q+o8tUFbfwnUEggttIgwro1ZWjdYdNzMBh!/4AnNa0hgDaRsiiAsMiY+tMlvIbHghnFy5JAbY7MTJY=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2818
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4029

On 5/12/2011 5:47 PM, Nancy 3 wrote:
> On 12/05/2011 5:32 PM, markspace wrote:
>> On 5/12/2011 1:56 PM, Nancy 3 wrote:
>>> There's also the minor little matter of number crunching performance
>>> going straight to hell if every little add or multiply suddenly has
>>> some test-and-branch instructions added near it.
>>
>> I believe arithmetic overflow could be handled efficiently at the
>> machine level, without the need for an explicit test-and-branch. I
>> haven't looked at any datasheets recently, but I recall most CPUs have
>> an option to trap, automatically, on overflow detection.
>
> I'm sorry. I assumed you wanted an ArithmeticException or some other
> Java exception on overflow, rather than an application fault ala SIGSEGV
> that brings down the whole JVM. :)

There are two separate issues:

1. How to detect. That needs to be done as efficiently as possible,
presumably using hardware features where available.

2. How to report. Typically, the operating system would turn something
like that into a signal. The JVM would set its own handler for the
signal. That handler could e.g. force a Java throw into the thread that
trapped. One hopes that the overflows will be rare, so the reporting is
not performance critical.

Patricia