Todd,
I have two issues that we might want to think about at this point.
First, in the long term, it could be well-worth adding JNI support into the
i386 build of decaf. I'm thinking of two main advantages that this gives.
First, it would help modularize decaf so that extensions could be added
without having to recompile or possibly even reboot decaf. Second, there
are a number of rather large JNI implementations of things that aren't
exactly our highest priorities now, but may be in a year or two. I'm
specifically thinking of things such as Java3D/Glide support. It seems to
me that there is an open source Java Glide implementation in the works that
uses JNI (I could be mistaken in this though - probably am. :) Having decaf
able to use JNI libraries in ELF format could be extremely useful down the
road, even if more difficult to implement now than rewriting the classpath
native code. This is just a decision we don't want to make without thinking
about all of its implications down the road. Of course, the answer may be
just rewriting again later down the road.
Second, while you are rewriting common/decaf from scratch, wouldn't this be
a good time to implement multiple processes? My thought is that the
ClassLoader approach we previously discussed gets the basics, but it would
be great to have each process have its own heap/stack. (Class definitions
would go in a shared heap.) I have an unfinished web page that goes into
more detail but I haven't gotten it on my site yet. I'll try to do that
soon. The main advantage of this approach is that we can then detect and/or
limit how much memory a particular process uses. For instance, a user may
want to limit an applet to being able to use only a third of the computer's
memory at most as a safety precaution. It is much easier to design
something like this in at the beginning or during a rewrite than to kludge
it in later.
What are your thoughts?
Do you want to take time for this?
How can I best help to implement this during the rewrite?
Regards,
Avery J. Regier
> -----Original Message-----
> From: Todd L. Miller [SMTP:[EMAIL PROTECTED]]
> Sent: Wednesday, February 02, 2000 9:30 AM
> To: [EMAIL PROTECTED]
> Subject: [JOS-Kernel] progress update
>
> After spending two weeks (or so) trying to get the classpath
> native libraries working, I've given up on them, especially since they'd
> require JNI, where doing all that work would only help the host build. So
> I decided to just go with their class library, and write the VM-specific
> bits directly into decaf, the same way we do native methods now, and leave
> porting native->BCNI/native code to whoever uses it. (Including myself.)
>
> So started trying to do that, and quickly ran smack into the
> back-end ugliness that I had mentioned wanting to rewrite at some
> point. It may well have been possible to write the VM-specific code
> without a rewrite, but it would have been unbelievably ugly -- so I've
> started a clean-slate re-write of everything in the common/decaf
> directory. (Since JM's code tends to be much cleaner than mine, and I
> don't fully understand great big chunks of it, I'm leaving well-enough in
> common/nativecode alone. I'll re-write whatever chunks of the
> arch/*/nativecode stuff seems appropriate, but most of that is in much
> better shape than common/decaf, and I don't think much work will be
> necessary.) I should be done with the re-write in less than two weeks,
> and the VM work for classpath ought to be done by at most a week later.
>
> Anyway, my apologies to those of you that have been sitting on
> their hands while I've tried to get my act together.
>
> -_Quinn
>
>
> _______________________________________________
> Kernel maillist - [EMAIL PROTECTED]
> http://jos.org/mailman/listinfo/kernel
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
