From: Godmar Back (gback@cs.utah.edu)
Date: Mon Nov 16 1998 - 02:57:53 EST
>
> > On the other hand, preallocating will be a good -- and the only possible ---
> > alternative for tackling OutOfMemory exceptions.
>
> Couldn't we just create an OutOfMemory object at VM start-up time, and
> keep it at hand for whenever we need to throw such an object? Would
> this violate any rule of the JVM Specification?
No, this is exactly what I have in mind, and in fact that's what I'm
doing in my personal project. It's still all half-assed, given that
we don't propagate out of memory conditions through the VM yet.
>
> > ad 3), would storing it in JNIEnv work. I assume you mean the
> > thread-specific data structure that JNIEnv points to
>
> Actually, I was referring to whatever mechanism the current
> implementation of JNI uses to store exceptions, so that the interface
> would be completely uniform. But then, we'd have to create real
> instances of the exception object, but you have already explained that
> we can't do that in 2).
Three comments:
+ The current implementation doesn't use JNIEnv*, it uses kaffe.util.Ptr's
in java.lang.Thread to store exceptions.
+ Independent of what you use, you have to delay the creation of the
exception object (as you say). So you have to store something like
classname/mesg for some time and at some time create the exception
and throw it, which would indeed make it less "uniform".
>
> Anyway, I still don't like very much the idea of modifying the return
> values of the functions. Can't we just rely on the fact that, if the
> class name is NULL, no exception was thrown, otherwise the returned
> value is meaningless?
>
I'm not sure what you mean.
I reused the return value where functions had a return value (getClass,
for instance), I added a return value for functions returning void,
processClass for instance. There is no way around that.
The caller of a function has to know whether the function succeeded or
not. This must be communicated somehow, and the return value is the
most efficient way to do that. (Actually, I don't always use the return
value: in findInJar, I use hand.type; CP_INVALID means failure -- but
like I said, I tried to stick as close as possible to what was there).
After checking the return value, the caller knows whether it can
proceed, or whether it must clean up and propagate the failure to its
caller by returning.
- Godmar
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:03 EDT