> Based upon a whole 5 seconds of thought, I think you can handle both the "code
> itself" and "functions called from w/in runOpcode" cases the same way. Since
> they're (just about) frame methods, you can call a frame/java_thread method to
> pop the appropriate stack frames in the classical fashion. Right?
Now that you've written the thread pointer in, yes. Otherwise,
whose stack do I pop/pc do I manipulate? I want to call
thread->throwExecption( new IndexOutOfBoundsException() ) and have
everything happen automagically. The problem is the return values --
runOpcode() /must/ return, which (AFAIK) means that the function called
from runOpcode() /must itself/ return, and in some fashion that prevents
runOpcode() from doing Bad Things. The obvious way would be C++
exceptions causing a jump to the throwException() handler, which does the
Right Thing w.r.t. to its java_thread (and, BTW, also means that I don't
have to make sure that /every/ function gets the current thread pointer),
so that the next time the java_thread runs, it's running the
exception-handling opcodes, and then returns to the scheduler (which
might be somewhat problematic). Since, AFAIK, JJOS doesn't support
exceptions, that route is closed.
Without exceptions, you can pass the thread along, (just modifying
all the function headers is non-trivial) but the problem
of returning to the scheduler still exists.*
> Based upon another whole 5 seconds of thought, the only nasty problem I can
> think of is (if there is?) an "out of memory" exception (it would Truly Suck to
> be out of memory and then have to allocate an "out of memory" exception to
> throw). One might want to have a preallocated exception allocated for that
> case.
Yes. The problem I was thinking about had more to deal with the
problem of creating a java instance (i.e. IndexOutOfBoundsException) from
the nativecode that didn't have access to the classloader. Though this
could probably be gotten around.
-_Quinn
* The only idea that would save me from having to rewrite all the return
values and function calls would be some bit of (machine?) code that would
pop the stack until it got back to scheduler, perhaps set at the beginning
of the runOpcode() call. But I have no idea how to do this.
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
