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@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@cs.uiuc.edu Sent: Friday, March 26, 1999 5:06 PM To: squeak@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.
All -
Please forgive a newbie for stepping in, but I've been (quietly) looking at Squeak for awhile and have examined this issue a little for the purpose of creating small, configurable VMs.
Andreas Raab writes:
I'm not sure what you understand by plugin naming conventions... [snip]
I think a naming convention must address the following concerns :
1) At the moment, it seems all named primitive method names must be unique across all classes, with the possibility of collisions higher than the normal case with Smalltalk. I'm not sure if there is a collision between names across modules. This is a side effect of the C translation - there's really no reason why the class name can't be prepended to the method name.
2) There should be a way to handle the named primitive call where some VMs have them external, and others internal, with the Smalltalk code glue indifferent. As I understand the Mac code, the search is done in either one or the other depending upon the call. It seems like a minor fix to have the function searched in the supplied module name, then in the VM on failure. This would also allow the overriding of malfunctioning or "in-the-process-of-enhancement" primitives. Currently, moving the Balloon classes to an external module requires modification all of the primitive calls.
3) Mac people in particular might be turned off to the Squeak directory containing piles of plug-ins - there should also be a (platform-dependent?) convention for collecting plug-ins that will be searched for.
Regards -
=================================================== Duane Maxwell dmaxwell (at) launchpados.com CTO http://www.launchpados.com Launchpad, Inc. (619) 578-8500 x226
Information contained herein is my personal opinion and not necessarily that of Launchpad, Inc. ===================================================
squeak-dev@lists.squeakfoundation.org