Hi Todd;
> > 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...)
Not only that, but (I think) both JIT and Hot-Spot type things will
benefit. Although, to be perfectly honest, I haven't really thought too
deeply about it yet (my attention budget is a trifle, er, overspent at
the moment).
> 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).
Well, that's certainly a step in the right direction, although I must
admit to some surprise -- that's an awfully big improvement -- what, a
factor of almost 20? Don't know whether to be happy at the improvement
or embarrassed about there being so much room for it!
On the other hand, if we get our act totally together with respect to
GC, the Perfect Performance would be closer to zero, right? Except for
classes that have static member variables, right? I remember some big
debate on the Java lists about what to do about classes that had those
static vars (e.g., a counter that got incremented every time an instance
got made) -- it wasn't really good form to simply gc the class after the
last instance got reaped/gc-ed/finalized, because the count would get
reset/hammered. Does anybody out there know what the Party Line is on
this issue?
> 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.
OK. Best of luck. Unfortunately, I will not get as much done as usual
this weekend due to schedule conflicts...
Later!
-jm
--
==== John Morrison
==== MaK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== http://www.mak.com/welcome.html
==== vox:617-876-8085 x115
==== fax:617-876-9208
==== [EMAIL PROTECTED]
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
