2017-05-11 11:34 GMT+02:00 Clément Bera <[email protected]>: > > > On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo < > [email protected]> wrote: > >> 2017-05-10 13:38 GMT-03:00 Clément Bera <[email protected]>: >> > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo < >> [email protected]> wrote: >> >> >> If it is a plug-in, why does it need VM recompilation? >> > >> > Internal plugins require VM recompilation. Only external plugins do not. >> >> It was more of a semantic question, I'd expect a plug-in to be that, >> pluggable, as you say external plugins are. >> Or what is the "pluggability" of such plugins? >> > > I would say there is 3 levels of pluggability: > 1 non optional internal plugin, pluggable because it can be replaced by > another internal plugin implementing the same API at VM compilation time. > Used for modularity of specific aspects of the VM. > 2 optional internal plugin, pluggable because it can be removed / added / > replaced at VM compilation time. Used to improve performance over external > plugin or to access VM functions not exposed to external plugins. > 3 external plugin, pluggable because it can be removed / added / replaced > after the VM is compiled. Used for all other plugins. > > So they're all pluggable in some way. > > External plugins have to use a well defined API for all interactions with VM. Internal plugins not only could have access to unexposed functions, but can also inline some of these functions as recently introduced by Eliot ( https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/7fa0184ef8c7c8badb70942c5f17693f8e622426), so the performance might be a criterion of choice.
>From a packaging POV, making a plugin external is a source of trouble versus embedded internal plugins. The number of possible combinations can rapidly explode (think of testing). It is essentially for letting user choose: - to not embed the plugin * because he knows he ain't gonna need it, and he wants to limit the memory footprint * or because the plugins expose some security issues - to replace a plugin with an alternative version - to produce his own plugins without bothering to recompile the whole VM (or just update the VM without the need to update the plugin because the major revision of API did not change) >> Disclaimer: I don't know about the VM internals (*), and this is not a >> complain of any sort. I just wonder it is called that way. >> >> Regards! >> >> Esteban A. Maringolo >> >> (*) I did compile a Squeak VM a decade ago (added two primitives) but >> nothing more than that. >> >> >
