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] |
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] |