[Pharo-project] [Vm-dev] Re: Can OSProcess functionality be implemented using FFI instead of plugin?

Eliot Miranda eliot.miranda at gmail.com
Fri Jan 22 21:35:17 UTC 2016

On Thu, Jan 21, 2016 at 6:24 AM, Denis Kudriashov <dionisiydk at gmail.com>

> 2016-01-21 15:18 GMT+01:00 Denis Kudriashov <dionisiydk at gmail.com>:
>> Hi
>> 2016-01-21 13:43 GMT+01:00 Mariano Martinez Peck <marianopeck at gmail.com>:
>>> I was thinking the following. Having to distribute the FFI wrapper (take
>>> as an example the myself wrapper) with the .ston files is a bit of a pain
>>> with MC.  So I was thinking...what if FFISharedPool has all the machinery
>>> to allow FFI lib wrapper developer (the developer of the MySQL wrapper), to
>>> autogenerate the ston file as we said, BUT, the ston file is stored as
>>> methods in the MYSQLInterface subclass? Probably under a "autogenerated"
>>> protocol. That way, it's very easy to distribute and in addition, at system
>>> startup it's easier to "search" for the "ston files".
>>> The only drawback is the for very large ston files MC will suffer a
>>> bit.. but..
>>> Thoughts?
>> After reading this thread I have no understanding why "platform
>> constants" information should be distributed as ston files? Why not
>> generate smalltalk classes or methods for each platform? They will
>> initialize pool variables directly when platform change happens. And no
>> problems with there distribution
> In your example it can be methods on MYSQLInterface class side like:
> MYSQLInterface>>initWindows64Declarations
> ConstantA := 1
> ConstantB := 5
> MYSQLInterface>>initWindows32Declarations
> ConstantA := 2.
> ConstantB := 6
> MYSQLInterface>>initUnix32Declarations
> ConstantA := 3.
> ConstantB := 7
> And this methods can be published in separate packages if needed

Let's measure this.  Let's say we have 8 platforms (that's an
underestimate, because different Linux distributions may have different
values for certain constants), but 8, which is 4 basic platforms times 32-
& 64-bits.  We have Mac x86 32-bit, Mac x64 64-bit, Windows x86
32-bit, Windows x64 64-bit, Linux x86 32-bit, Linux ARM 32-bit, Linux x64
64-bit, and soon enough there will be more.  Further, there may be
different versions over time.

So each of those initialization methods has
- 1 slot for the global variable to be assigned
- 1 slot for the literal value to assign to it
- 3 bytes of bytecode per initialization for small methods, 4 for large
methods.  Let's say 4.

So the overhead in 32-bits is 12 bytes per constant, and in 64-bits is 20
bytes.  So the overhead per constant for all platforms is 96 bytes per
constant in 32-bits and 160 bytes per constant for 64-bits.  A full system
with sockets, files, a database connexion etc could easily exceed 100
constants.  I think it would be nearer 1000.  So the overheads are in the
10- to 100-k byte range (100k ~= 0.5% of the image) on 32-bits.  That's low
but it's also pure overhead.  Every GC has to visit them.  Every senders
and implementors has to visit them, but they offer nothing of value.
Whereas the small parser for whatever notation is used to store the
constants externally (if they are needed in a given deployment) has a small
constant overhead; its simple code.

Further, you still need the machinery to export the constants to be able to
generate these initialization methods.  If you've got the machinery and you
don't need the methods why bother to generate the methods?

As the Scots say, many a mickle makes a muckle.
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160122/3113439a/attachment.htm

More information about the Vm-dev mailing list