<br><br><div class="gmail_quote">On Sun, Mar 7, 2010 at 3:24 PM, Gilad Bracha <span dir="ltr"><<a href="mailto:gbracha@gmail.com">gbracha@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I'm all for it, and hope that John or Eliot can mentor. </blockquote><div><br></div><div>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:</div>
<div><br></div><div>1. I designed and implemented the VisualWorks THAPI system, a threaded extension to the VisualWorks FFI.</div><div><br></div><div>2. I have a functional prototype of a multi-threaded FFI for the Cog VM based on David Simmons' VMs.</div>
<div><br></div><div>1's architecture is poor, being complex, slow and not very general (allows only FFI calls to be threaded).</div><div>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).</div>
<div><br></div><div>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,</div><div>- 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)</div>
<div>- that type coercion code also has to be lifted (e.g. character conversions on strings, null termination, type coercion)</div><div>- 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)</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>best</div><div>Eliot</div><div><br></div><div><br></div></div>