[Vm-dev] Recreating live coding in CPython 3.5

Nicolai Hess nicolaihess at gmail.com
Thu Oct 12 09:58:51 UTC 2017

2017-10-12 10:50 GMT+02:00 Dimitris Chloupis <kilon.alios at gmail.com>:

> Thanks Ben actually your first link was the first thing I read when I
> googled become. I dont think VM lookup benefits me in my case as this is
> already handled by the Python VM.
> You other tlinks are JIT VM related, Python is not friendly to JIT because
> its creator believe that performance enhancement should come from wrapping
> C libraries and wants to avoid the cost of more complex VM . In the case of
> Python this is easy to follow because Python has a ton of high performance
> libraries which by the way almost never are used when comparing Python with
> other languages speed wise (kinda fare if you just compare language
> implementations). Pharo does benefit a lot more from JIT VM as it does not
> have as many libraries targeting high performance.
The interesting parts in this "JIT VM related" links is, if you happen to
write a JIT VM , you have to take care of the language features smalltalk
provides. For example, you can not just optimize away
smalltalks context chain by replacing it with native stack frames, without
losing the features a smallalltak method context provides on the language
This language features are already explained very well in the blue book,
but the links about the cog vm and other vm and jit vm papers for dynamic
langueges are helpful too.

I don't know which language features (late bindng, method lookup ,
thisContext / execution context, become operation, etc) are *necessary* to
provide the "smalltalk art of live coding".
Or to what extent this features exists in other language. But it is one
reason why it is "easy" to build within smalltalk itself this smalltalk
environment (edit / compile/ run / debug smallalk code from within a
running smalltalk environment).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20171012/43364861/attachment.html>

More information about the Vm-dev mailing list