[Vm-dev] Cog status & FFI directions [was rearchitecting the FFI implementation for reentrancy]

[Eliot Miranda]

2009/8/6 Göran Krampe <goran at krampe.se>

>
> Hi Eliot and all!
>
> Eliot Miranda wrote:
>
>> Hi All,
>>    I'm looking at making the Squeak FFI reentrant to support nested calls
>> and possibly threading.  The current FFI has a couple of issues which
>> render
>> it non-reentrant.
>>
>
> The tech stuff is over my head, but I do have three questions related to
> this:
>
> 1. What about Alien? Shouldn't we try to move towards Alien instead of
> current FFI? Or is that too much work at this point?


I intend to merge Alien into the current FFI to allow the current FFI to
marshal Aliens.  Aliens are fine for modelling external data but the Alien
FFI call-out mechanism is a little too naive for general use  It works well
on x86 but has issues on anything with an exotic calling convention (passes
arguments in integer and/or floating-point registers).  And see the next
point about callbacks.

>
>
> 2. Callbacks has been a sore point in Squeak for a long time. AFAIK there
> is a patch available on www.squeakgtk.org/wiki/download.html, not sure
> what it does or if it is the original patch from Andreas when wxSqueak was
> being built. wxSqueak had a patched VM I recall. Perhaps that stuff is not
> related.
>

One thing that IMO is much better about Alien is the callback mechanism
which allows one effectively to pass function pointers to blocks.  The
current FFI's callback mechanism is weak.  It simply does a process switch
away form the process calling out and requires further work in the image,
e.g. a process waiting on a semaphore that is signalled by external code, to
then collect information for performing the callback. So adding in the Alien
callback mechanism is also something I intend to do.



> 3. Could we possibly ask for a status update on Cog and related activities?
> We are itching for news! :) Also curious about your interest in Factor and
> its lower bowels (definitely cool stuff going on there).


The status is as follows.
The Cog stack VM os being reviewed for release to the community.  We hope to
have this done soon, certainly before the end of September, but we're busy
and this isn't on the critical path.  Once it is released there will have to
be some integration and merge activities before it is part of the standard
VMs because we have effectively forked (although not a lot).

The first incarnation of the Cog JIT is complete (for x86 only) and in use
at Qwaq.  We are gearing up for a new server release and the Cog VM is the
Vm beneath it.  The next client release will include it also.  This VM has a
naive code generator (every push or pop in the bytecode results in a push or
pop in machine code) but good inline cacheing.  Performance is as high as 5x
the current interpreter for certain computer-language-shootout benchmarks.
 The naive code generator means there is poor loop performance (1 to: n do:
... style code can be 4 times slower than VisualWorks) and the object model
means there is no machine code instance creation and no machine code at:put:
primitive.  But send performance is good and block activation almost as fast
as VisualWorks.  In our real-world experience we were last week able to run
almost three times as many Qwaq Forums clients against a QF server running
on the Cog VM than we were able to above the interpreters.  So the Cog JIT
is providing significant speedups in real-world use.

I am (clearly) looking at FFI issues right now.  In the Autumn I intend to
start work on a less naive code generator, a better object model and a
faster garbage collector, the three of which should raise performance levels
to VisualWorks levels, i.e. a further 2x to 3x increase over the 4x - 5x
already achieved for pure Smalltalk execution.

I expect we'll be in a position to release some version of the Cog JIT to
the community by Christmas.

I'll be giving a guided tour of the current Cog JIT VM at SqueakFest LA on
Monday.


>
> regards, Göran


Best
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20090806/29e1d547/attachment.htm