This is the mail archive of the
mailing list for the Java project.
Re: FYI Patch: Fix memory leak PR 12475
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.
> > 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
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.