> I am sorry about that, I havn't started to write
> the jju64 class. But will u intergrate into it ?
Would be the jji64 class ( we have the unsigned version ), but
yes, it would be very easy to integrate -- jlong right now == jju64, so
I'd only have to change the typedef to make it a jji64. (If your jji64
class provides the same operations, that's the only line of code that
would be changed, aside from the #include "jji64.h" (or
whatever).) Thanks.
BTW -- I'm in the middle of squashing bugs in the (sort-of) new scheduler
right now, so I'm getting very close to done. (I hope!) I haven't done
extensive testing on the classfile parsing, but since the actual parsing
algorithm is virtually identical, I'm not too worried about it.
interp.cc remains to rewrite (closer to port, actually). I've decided on
taking a simple but (I hope) effective approach to handling resolution,
where you always ask the potentially unresolved object for something (e.g.
the method reference's class) expecting it to be unresolved (e.g. passing
it a constant pool/class loader/etc) where the particular C++ class
representing that object can cache that resolution or not, as it sees fit.
Basically, this moves the resolution logic from the interpreter to the
objects, where it belongs. Storage efficiency could be gained by unioning
the resolved and unresolved data sets, but I'm not certain this would be
wise, looking at potential problems in sharing class definitions across
classloaders. We'll see.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
