On Sun, Mar 7, 2010 at 3:24 PM, Gilad Bracha <gbracha at gmail.com> wrote:

> I'm all for it, and hope that John or Eliot can mentor.


I would like to mentor something in this area, but I think the basic goal of
a cross-platform system is not achievable in GSoC this summer.  A
specification of a non-blocking architecture and a reference implementation
may be possible.  Cross-platform is too big for a summer project and will
require input from dialects and vendors.  What affects my thinking is the
following:

1.  I designed and implemented the VisualWorks THAPI system, a threaded
extension to the VisualWorks FFI.

2.  I have a functional prototype of a multi-threaded FFI for the Cog VM
based on David Simmons' VMs.

1's architecture is poor, being complex, slow and not very general (allows
only FFI calls to be threaded).
2's architecture is rather simple, rather fast and very general (allows
threading to be much more widely used, e.g. calls within plugins can be made
threaded by surrounding them with two calls, disownVM and ownVM).

3. I have looked at marshalling semantics in the context of the VW FFI,
Andreas' Squeak FFI & Alien, and am still of the opinion, one shared by
David,
- that the generation of marshalling stubs has to be lifted up into
Smalltalk based on simple ABI compilers that somehow (e.g. through RTL)
communicate down to a JIT that generates and caches marshalling code (i.e.
that VM attempts to interpret simplified call specs, as happens in the VM
and Squeak FFIs are in general doomed to poor performance and bugs)
- that type coercion code also has to be lifted (e.g. character conversions
on strings, null termination, type coercion)
- that one be able to depend on a pinning garbage collector to deal with the
issues of passing objects through the FFI (although there are workaround
hacks that can serve temporarily)

I don't see the point of spending a GSoC trying to implement an obsolete
(unthreaded, lowest-common-denominator) cross-platform FFI; it won't get
used.  I do see benefit in an open-source reference implementation that
provides some of the above (at least threading/non-blocking).  If people
agree that an open-source reference implementation is worth pursuing, then I
will happily mentor.  What the starting point is will depend on to what
extent Cog has been open sourced  (Teleplace may choose to open source
single-threaded Cog initially, keeping back the threaded FFI for a while, it
may not open source Cog at all; we'll see :) ).  There are other starting
points (current Squeak VMs, GST, Newspeak).

But the outline above is a move towards better cross-platform commonality,
not less, because it's an architecture in which the image does more (type
coercion, compiling call signatures to RTL sequences) and the VM (except for
the threading ;) ) does less.  And so this direction does lead towards
better cross-platform facilities.

best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100309/1fcc5664/attachment.htm