links to this page:    Squeak VM Plugins

Clément Bera
<bera.clement@gmail.com>	Thu, May 11, 2017 at 11:34 AM
Reply-To: Pharo Development List <pharo-dev@lists.pharo.org>
To: Pharo Development List <pharo-dev@lists.pharo.org>



On Wed, May 10, 2017 at 8:12 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

    2017-05-10 13:38 GMT-03:00 Clément Bera <bera.clement@gmail.com>:
    > On Wed, May 10, 2017 at 5:28 PM, Esteban A. Maringolo <emaringolo@gmail.com> 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. mandatory 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.

Nicolas Cellier
<nicolas.cellier.aka.nice@gmail.com>	Thu, May 11, 2017 at 12:14 PM
Reply-To: Pharo Development List <pharo-dev@lists.pharo.org>
To: Pharo Development List <pharo-dev@lists.pharo.org>


2017-05-11 11:34 GMT+02:00 Clément Bera <bera.clement@gmail.com>:

.....

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)