This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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]

IA64 exception handling memory leak


Peter Buhr supplied a small test program to David Mosberger that repeatedly
throws exceptions.  He pointed out that on IA64 compiled with gcc3.x this
leaks on the order of Gigabytes a second.  (And his message predates April
1.)

I had previously observed that we couldn't run the full Java UCSD benchmark,
since the exception test ran out of memory on a machine with "only" 2GB.

I've attached a patch that fixes both problems.  Unfortunately, it warrants
some discussion.

Aside from some easily fixable issues, the main problem is that
_Unwind_RaiseException and friends (in unwind.inc) have no mechanism for
deallocating data structures hanging off the frame state.  Apparently on
most architectures the frame state is a single structure which requires no
dynamic allocation.  On IA64 it's more complicated and has fields that
require deallocation.

The attached patch introduces a suitable "destructor" call for frame states.
Since I didn't want to touch all ports, this defaults to doing nothing.
Unfortunately, it needs to be invoked in many places.

Eventhough I was initially inclined to let this slide, I think the leak is
bad enough that it needs to be fixed in 3.1.  Is it OK to check in the
attached patch there?

I'm less certain about what to do with the trunk.  David Mosberger points
out that this hook may not be necessary with the new unwind library, since
it generates and then executes "unwind scripts", which have bounded size.
Thus the dynamic allocation could be completely hidden inside the
IA64-specific parts of the unwinder.  I think we're too close to the 3.1
release date to do this there.

Does it make sense to just leave the trunk as is, and let the new unwind
library solve the problem there, thus leaving the generic code cleaner?  Or
are there other architectures that also need the frame-state-destructor
mechanism and currently leak in the unwinder?


Hans

Attachment: exc_diffs
Description: Binary data


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