Hi again Todd --
1/. As you may have noticed, I didn't get chance to update stdlib with some
ASSERT macros last weekend. I *might* get chance this evening (but don't
hold your breath).
2/. I meant the Java exception OutOfMemoryError and
InvalidMonitorStateException .. as far as I could see, these and similar JVM
exceptions aren't thrown and nor were they in the old code. But correct me
if I'm wrong. As I said in my first mail, I'd be interested in trying to
help sort this out if they are not yet functional.
Another comment on code structure (which might have come out of the various
discussions that have been going on, but I haven't had chance to read them
yet): I think it would be useful to have a Process class in the C++. It
would hold information about it class loader, threads/thread group, process
id and, when we get some security infrastructure, the identity of the
process owner etc.
-- George
> -----Original Message-----
> From: Todd L. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: 08 April 2000 07:37
> To: [EMAIL PROTECTED]
> Subject: RE: [JOS-Kernel] new_decaf CVS branch
>
> > 1. The code would be cleaner, shorter and more flexible if you used an
> > ASSERT macro. For example, I saw a couple of places with this kind of
> thing:
>
> You're right, and I'm amazed I didn't realize this on my
> own. Thanks.
>
> > 2. There seem to be quite a few places where exceptions should be thrown
> > (illegal monitor state, out of memory etc) but aren't. I'd be interested
> in
> > trying to help out in this area when the interpreter's up and running.
>
> Unfortunately, C++ exceptions aren't supported on the i386 build
> yet, so I never gave much thought to them. They are, clearly, the Right
> Way to do things*. I'll be looking into some static-link fu for
> dynamic_cast<>(), so maybe I'll look into exceptions at the same time.**
> I don't think, basically, that I should spend time kludging something up
> that wouldn't work as well anyway.
>
> Anyway, I hope you get more time to look at the code; your
> comments will be valuable.
>
> -_Quinn
>
> * outline:
>
> decaf_main () {
> try { /* everything before the call that starts the intreperter */ }
> catch ( Exception e ) {
> /* Try to do something intelligent, e.g. a garbage
> collection
> and try again; if still no good, abort. */
> }
> scheduler->start();
> }
>
> Frame::interpret() {
> try { /* switching on the bytecode */ }
> catch ( Exception e ) {
> /* throw e into Java. (Unless we want try and
> do something intelligent first. Exceptions are
> JavaObject
> subclasses, so this shouldn't be too hard;
> return to scheduler after exception-handling frame
> is on the thread's stack, to be run on the next
> iteration. */
> }
> }
>
> **: dynamic_cast<>() should be entirely user-space. Messing about with
> the frame stack, etc, may not be, which means it wouldn't work.
>
>
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
