Jason Baker wrote:
> As for classes loaded by the catch body, is this
> really a problem? Once a StackOverflow has been dispatched, we
> should be able to throw a new one and make progress.
Right, we should only be forcing the load of classes referenced in the
catch clause, and not necessarily
Patrick Tullmann <[EMAIL PROTECTED]> writes:
> Tim Stack wrote:
> > Preloading in this case means checking if a class references
> > StackOverflowError or any of its ancestors and then having the class
> > loader load them in, or we just treat them as "special classes" that
> > magically resolve
Tim Stack wrote:
> Preloading in this case means checking if a class references
> StackOverflowError or any of its ancestors and then having the class
> loader load them in, or we just treat them as "special classes" that
> magically resolve to system classes regardless of the class loader.
I'm
I notice that JAR files are not set up as binaries within the Kaffe
repository.
Can someone do this?
(if it's not teaching my gran to suck eggs you just need to add .jar
to the repository: cvswrappers file)
Nic
I sent a fix for the current HttpURLConnection last week - I haven't
had any feedback from this.
Was everybody happy with it? Is it going in CVS? Can someone tell
me?
As an aside on this I notice that JDK1.3 is doing persistent
connections which is the other side of what I am doing with this
cl
Timothy Stack <[EMAIL PROTECTED]> writes:
> > Just preload it once and for all and throw the same type in all threads,
> > even those that run in a classloader context.
> > This should be "close enough".
>
> Kaffe already does this, the problem is when it tries to match this class
> to the o
> Just preload it once and for all and throw the same type in all threads,
> even those that run in a classloader context.
> This should be "close enough".
Kaffe already does this, the problem is when it tries to match this class
to the one in the catch clause. Specifically, line 603 in exce
Just preload it once and for all and throw the same type in all threads,
even those that run in a classloader context.
This should be "close enough".
- Godmar
>
>
> hi,
>
> I've run into an odd problem that I don't know quite how to fix.
> Basically, a stack overflow isn't handl
>
> I've noticed that Kaffe gives some strange results in some situations;
> one particular case that I noticed is java.io.BufferedWriter. Running
> the attached class as "kaffe net.wuffies.japi.Japize -c
> java.io.BufferedWriter" I get duplicate lines for some methods. In
> particular, the meth
I checked in these fixes for freeing explicitly managed objects in
Kaffe. Thanks Tim!
Users who have been paying attention to Kaffe's memory footprint
should try this latest CVS version. I'm curious how much memory Kaffe
was actually leaking...
-Pat
- - --- --- -- --
hi,
I've run into an odd problem that I don't know quite how to fix.
Basically, a stack overflow isn't handled particularly well, especially
when there are class loaders involved. Since we execute a good deal of
code to throw the exception it eats up even more stack and we risk going
past the
Hi,
I'm attaching a Java program and perl script I wrote to test
compatibility between the JDK and free versions. It's in its early
stages but from my testing so far, the results are already interesting.
Consider both the attached files to be under the GPL (sorry about the
lack of legal headers).
12 matches
Mail list logo
