Re: FYI Patch: Fix memory leak PR 12475

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Thursday, Oct 2, 2003, at 22:01 Pacific/Auckland, Andrew Haley wrote:
 > 
 > > Bryce McKinlay writes:

 > > Thirdly, the factoring of stack traces is already weird because of
 > > Classpath compatibility requirements.
 > 
 > I don't think there is anything wrong with the VMThrowable interface. 
 > It is our implementation of it that is the problem ;-)

Point taken, but it doesn't help.

 > > Fourthly, there are some very tricky security issues.  In
 > > particular, access to raw stack traces needs to be restricted to
 > > a few places.  I intend to do this by carefully using native code
 > > and friend access.
 > 
 > My basic idea is to put the common stack-trace infrastructure - ie
 > the parts used for both exceptions and security - in a
 > stacktrace.cc or something similar. natVMThrowable will use that
 > and StackTrace.java etc will go away.

Right.  That's what I meant, I think!

 > NameFinder will remain, for now, but only to do source/line info
 > lookups. Making it native means no security problem, alleviates the
 > passing-around-RawData's mess, and makes it more convenient to use
 > because the places this is used are native anyway.

Exactly, yes.

 > > Fifthly, there are some tricky efficiency requirements.
 > 
 > Definitely. For calling-classloader checking, for example, we only want 
 > to walk the stack as far as is needed to find the caller.

Right.  This is going to get worse, because at the moment we usually
just follow a linked list but at some point we'll need to use the
unwinder machinery.

AG pointed out a while back the we can implement Class.forName() by
converting it into

forName (klass, true, getClass.getClassLoader()).

at compile time.

 > Also, we want to avoid allocations while doing security checks.

Yes, I can see how we might be able to do that.

Andrew.