This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: RFC Patch: garbage free StackTrace methods
- From: Tom Tromey <tromey at redhat dot com>
- To: Anthony Green <green at redhat dot com>
- Cc: java-patches at gcc dot gnu dot org
- Date: 26 Feb 2004 17:43:09 -0700
- Subject: Re: RFC Patch: garbage free StackTrace methods
- References: <1077841736.3462.282.camel@escape>
- Reply-to: tromey at redhat dot com
>>>>> "Anthony" == Anthony Green <green@redhat.com> writes:
Anthony> I recently noticed that we allocate new StackTrace objects
Anthony> for each class.forName() when we're looking for a class
Anthony> loader. Allocating a StackTrace object involves a couple
Anthony> more allocations as well. But a quick look at the code tells
Anthony> us that we can get the same thing done with no allocations.
Good idea.
I think Andrew and Bryce should really comment on this patch. In
particular I know Bryce has a big unsubmitted patch in this area, I'd
like to know how his changes interact with yours. (If his is still a
ways off then we should put yours, whatever its final form, in
sooner.)
Do we ever need the Class and not the ClassLoader? Perhaps we should
just change VMSecurityManager.currentClassLoader() to a native method
that does this. That's more classpath-y...
Anthony> + #else // HAVE_BACKTRACE
Anthony> + (void)maxdepth;
Anthony> + #endif // HAVE_BACKTRACE
These days we have the MAYBE_UNUSED macro for this situation, just
mark the parameter with it. (Might as well fix the other instance in
that file too...)
I'm not too thrilled with the code duplication, is there an easy way
to refactor?
BTW your patch got wrapped.
Tom