This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: DaCapo benchmarks

From: Bryce McKinlay <mckinlay at redhat dot com>
To: Andrew Haley <aph at redhat dot com>
Cc: java at gcc dot gnu dot org
Date: Mon, 07 Nov 2005 14:35:53 -0500
Subject: Re: DaCapo benchmarks
References: <63006.202.55.156.222.1128986731.squirrel@sqmail.anu.edu.au> <1129493766.5880.59.camel@localhost.localdomain> <47717.66.181.12.81.1129565596.squirrel@sqmail.anu.edu.au> <1129976855.4617.26.camel@localhost> <17263.30991.416136.696416@zapata.pink>

Andrew Haley wrote:

The gcc exception processing mechanism is designed to be very fast for
the "never thrown" case, but it is slower when exceptions are thrown.
I suppose gcj could change to optimize for things like this, but IMO
it would not be such a good idea for "reasonable" applications.
I'm very tempted to fix getValueOf() so that it does what its specification requires, but that would invalidate the benchmark.

Even HotSpot is slow for thrown exceptions (though not as significantly as GCJ), and Sun recommend against using exceptions to signal non-exceptional conditions. So in cases like this there is a pretty good argument for submitting a fix upstream, since the application will perform better on most/all implementations - not just GCJ.

However, its also true that exception performance will continue matter in many real-world apps, and anything that can be done to speed up throwing in GCJ would be good.

Bryce

Follow-Ups:
- Re: DaCapo benchmarks
  - From: Andrew Haley

References:
- Re: DaCapo benchmarks
  - From: Andrew Haley

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]