Hi;
Todd L. Miller wrote:
>
> > 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.
I'm afraid I don't understand: why can't you just call some sort of member
function like:
bool frame::throwException(java_object *);
or
bool java_thread::throwException(java_object *);
It would unwind the frame stack to the "right" frame (based upon either an
explicit exception stack or a traversal of the frames). frame::runOpcode would
simply return "true" to indicate that the thread should continue execution. The
next java_thread::runOpcode calls currentFrame()->runOpcode(), and you get the
"right" frame. (I'm presuming that exception handlers are simply different PC
locations within a given frame -- right?) I'm thinking this will All Just Work.
> 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.
I think the java_thread's java_class keeps a reference to its class loader lying
about, although I'll have to check.
> * 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.
Obviously, I'm hoping we don't need to do this...
-jm
--
==== John Morrison ==== MaK Technologies, Inc.
==== Chief Technology Officer ==== 185 Alewife Brook Pkwy, Cambridge, MA 02138
==== [EMAIL PROTECTED] ==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115 ==== fax:617-876-9208
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
