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.