Andrew,

> If this is already in place and I missed it, mea culpa.
> 
The 'mea culpa' is accepted - everything you were talking about is in there
;-) The addresses are *of course* cached - the OS dependent lookup gets only
invoked if the function has not been loaded before.

>  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.
> 
The overhead for invoking a (cached) named primitive can be substantial if
we're talking about stuff like Object>>at: or Object>>at:put: but given that
the primitive takes more than say 50 micro seconds the overhead shouldn't be
noticable at all. What happens when invoking a named primitive is:
	* Fetch the first literal of the method
	* Make sure it is an array of the right size
	* Load the session id and the function address from the array
	* If function address ~~ 0 and session id == current session:
		Call the primitive
	* Otherwise: do the slow lookup and everything else
[Just as a side note: The entire Balloon stuff uses named primitives and I
don't think that you would notice a measurable difference when switching to
indexed prims]

> Some thought ought to go to plugin library naming conventions and 
> version-testing conventions as well.
> 
I'm not sure what you understand by plugin naming conventions, but there is
a sort-of versioning system for the plugins: Whenever the VM attempts to
load the plugin it calls the plugins 'setInterpreter' function with a
version number and a vector of VM functions. The major version number of the
VM must match the major version with which the plugin was compiled and the
minor version must be at least of the minor version with which the plugin
was compiled. There is a unique list of exported functions from the VM (btw,
contained in 'sqVirtualMachine.h') and the plugin is linked against these
settings.

Note, however, that plugins can also be used to simply structure the VM. A
Squeak plugin can be added when the Interpreter sources are generated (see
Interpreter>>translate:doInlining:) and I actually understand Tim more like
he want's to have a simple way of getting rid of parts of the VM by just
excluding these guys from the list of plugins.

  Andreas
--
PLEASE NOTE NEW EMAIL ADRESS!

+===== Andreas Raab ========= (andreasr at wdi.disney.com) ==+
| Walt Disney Imagineering        Phone: +1 818 544 5016  I
I Glendale, CA                    Fax:   +1 818 544 4544  I
+======< http://isgwww.cs.uni-magdeburg.de/~raab >========+


> ----------
> From: 	Andrew C. Greenberg
> Reply To: 	squeak at cs.uiuc.edu
> Sent: 	Friday, March 26, 1999 5:06 PM
> To: 	squeak at cs.uiuc.edu
> Cc: 	recipient list not shown
> Subject: 	Re: VM cleanup (was Re: [VM] NCM performance report)
> 
> > 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.
>