Re: Query on stacktrace management logic

[Archie Cobbs]

Steven Augart wrote:
> > I still need a hook to not get the stacktrace filled in for
> > OutOfMemoryError - though perhaps I can do something without requiring
> > allocation using a different approach.
> 
> In Jikes RVM, we override a few of Classpath's implementations; we 
> have our own Object.java and (relevant to your case) Throwable.java, 
> for instance.  Hope this helps.

In JC I've taken the approach of keeping the last little bit of heap
memory reserved for OOM exceptions. If an allocation fails, we set the
"out of memory" flag for that thread, then throw an OOM. Subsequent
allocations (while "out of memory" is set) are allowed to dip into the
reserved memory. Once the exception is fully constructed, we reset the
"out of memory" flag.

Finally, there is one global "stackless" exception created at VM startup
for each possible exception type that the VM itself throws. These are
used as a last resort (this idea is from SableVM), where "last resort"
means another exception of the same type is thrown while trying to
create the first exception (i.e., recursively thrown).

> The biggest ugliness here is that the version the rest of Classpath 
> sees is not the same one as will actually be loaded at run time.  One 
> day this will probably bite us when Classpath adds some new (Java 1.5 
> or 1.6?) method or field to a class we override before we do it 
> ourselves, and some other Classpath class uses the new method or field.

I've "overridden" a few of the non VMXXX classses and JC is installed
as an "overlay" on top of a stock classpath installation. This means that
the bootstrap classpath must always include "jc.zip" before "glibj.zip",
but on the positive side upgrading is easy.

FYI, when I started working with Classpath I tried to respect the
Foo-VMFoo split and not modify any Foo classes but eventually decided
that it was too costly. E.g., every loaded class already has a Class
object (I don't create them on-demand), but you double that number
if you also have a VMClass object for each class. Fortunately with
Classpath it's easy to go either way as things are pretty well
documented.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com