> incremental step is to make it a method on the current frame (it keeps
> peeking to the current frame anyways for just about everything, and this
> will both make the code cleaner and faster by avoiding an unnecessary
> level of indirection).
Yup. Should have thought of that.
> I made the global isParent fcn a method of java_class.
It belongs there; I'm not sure why I didn't have it there the
first time.
> I separated out the various invoke opcodes into a function (for
> cleanliness' sake) -- this will be the focus of the "environment"
> effort.
Once the "enviroment" for java methods is ready, it should be
nearly trivial to extend to native methods, which will make things much
more efficient. (And provide an expansion point, if/when we implement
native shared libraries...)
> I think I'll have to make lots of changes to frame and java_thread --
> I'll want to cache the "helper variables" that currently get recomputed
> each bytecode, and I'll want to cache them (probably) on invocations,
> which will mean some code'll have to get divided up and reapportioned
> between the invocation code and the steady-state code.
Makes sense. Many of the things in run() are left over from
before it was made properly re-entrant.
Out of simple curiosity, I went ahead and let init() finish
executing; memory consumption is down to 1664K, which is a dramatic
improvement over the last time I checked it (~30MB, IIRC).
I've been working on monitors, mostly. Slow going; I've been busy
and they aren't particularly simple beasts. On the other hand, I won't
have to implement anything totally new; all the various subfunctions for
the monitors are already lying around.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
