> Dan's worries about image size in the recent NCM thread reminded me to ask a
> question I had almost let slip out of my mind:-
> when/who/how is the VM going to get cleaned out; by which I mean to ask if
> anyone is actively pursuing moving many of the 'extra' prims out into Plugin-
> land thus making a minimum VM much more easy to produce?

.. . .

> Along with minimum images, headlessness and loadable 
> partial-images, a small VM
> might make a practical scripting utility possible. It would 
> certainly load and
> startup more rapidly.
>
> So, is anyone already doing this?

Before assigning that task, let's see if we can't tune the primitive 
plugins somewhat better first.  I haven't studied the code for 
awhile, but as I recall, the present primitive plugin (at least for 
the Mac) performs a table lookup of the plugin name in the module 
tables with EACH AND EVERY CALL to the primitive.  Accordingly, 
primitives deep in an inner loop can face a substantial overhead just 
from the primitive calls.

So some sort of caching arrangement needs to be accomplished to assure:

	(1) that modules are loaded exactly once for each session in 
which they are used (but the caches must be cleared on image startup 
shutdowns;

	(2) that each primitive is looked up exactly once for each 
session in which it is used (likewise, with caches cleared on image 
startup/shutdowns; and

	(3) that the overhead of this protocol isn't itself large in 
comparison with the overhead of present-day primitive calls once the 
module is loaded and the primitive has been called at least once.

If this is already in place and I missed it, mea culpa.  But without 
it, let's leave critical innerloop-style primitives inside the VM 
until we have polished and refined the primitive plugin process 
somewhat; or else Tim's project (one that ought to be undertaken) may 
lead to a substantial degradation of performance.

Some thought ought to go to plugin library naming conventions and 
version-testing conventions as well.