<div dir="ltr"><div>Hi Jecel,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El lun., 21 ene. 2019 a las 22:27, Jecel Assumpcao Jr. (<<a href="mailto:jecel@merlintec.com">jecel@merlintec.com</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hernán Morales Durand wrote on Mon, 21 Jan 2019 18:13:45 -0300<br>
> I have some possible myths, but I'd like to confirm or reject:<br>
> <br>
> - All Smalltalk bytecode sets are stack-based VM. (?)<br>
> - Bytecodes are always fixed-size. (?)<br>
<br>
SOAR (Smalltalk On A RISC, now renamed as RISC-III) used a 32 bit<br>
register based instruction set and Smalltalk sources were translated to<br>
that. They did regret dumping bytecodes later in their project as some<br>
things became more complicated and the increase in memory use was very<br>
expensive at that time.<br>
<br>
<a href="https://apps.dtic.mil/dtic/tr/fulltext/u2/a172800.pdf" rel="noreferrer" target="_blank">https://apps.dtic.mil/dtic/tr/fulltext/u2/a172800.pdf</a><br>
<br>
SOM (Simple Object Machine) is a set of Smalltalk VMs where some of them<br>
represent code as abstract syntax trees instead of bytecodes.<br>
<br>
<a href="http://som-st.github.io/" rel="noreferrer" target="_blank">http://som-st.github.io/</a><br>
<a href="http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/" rel="noreferrer" target="_blank">http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/</a><br>
<br>
> - Most of the time spent by a VM is in the instruction interpreter. (actually it's in the GC right?)<br>
<br>
That will vary from one VM to another. On page 179 of the "green book"<br>
you can see a nice graph of the space and time used by different part of<br>
the Apple Smalltalk (from which Squeak evolved) and on page 177 you can<br>
find the numbers used to create the chart.<br>
<br>
<a href="http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/" rel="noreferrer" target="_blank">http://sdmeta.gforge.inria.fr/FreeBooks/BitsOfHistory/</a><br>
<br>
10.2% of the time in the fetch loop, 16.0% in the bytecode interpreter,<br>
39.2% in sends and returns, 22.6% in the memory management and 10% in<br>
primitives.<br>
<br>
Adding the first 3 numbers you get 10.2+16.0+39.2 = 65.4% in the<br>
instruction interprter while the GC is part of the 22.6% which is the<br>
memory management. That said, in Squeak gcc tricks really helped with<br>
the fetch loop and the stack VM greatly reduced the send/return<br>
overhead. So it might be the case that the GC dominates performance. Or<br>
not - we have to measure and see.<br>
<br>
> - You cannot serialize objects containing blocks. (IIRC one can use MessageSends)<br>
<br>
Given that the image contains blocks, that can't be true. Obviously<br>
serializing a subset of objects is a harder problem than just dumping<br>
memory, but I consider images a proof of existence.<br>
<br>
> - Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo I think).<br>
<br>
Little Smalltalk is a good example of taking a textual representation<br>
and bootstrapping an image from it. </blockquote><div><br></div><div>Yes, sadly some of the LS implementations were lost in time and need to be tracked now, <a href="http://www.littlesmalltalk.org">http://www.littlesmalltalk.org</a> is now chinese thing, PDST and Parla were based in LittleSmalltalk 3 but only accessible through archive: <a href="http://web.archive.org/web/20051025043437/http://www.copyleft.de/Parla/Parla.html">http://web.archive.org/web/20051025043437/http://www.copyleft.de/Parla/Parla.html</a>. There is another implementation now : <a href="https://github.com/0x7CFE/llst">https://github.com/0x7CFE/llst</a> however didn't checked yet.<br></div><div></div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">GNU Smalltalk didn't even use images<br>
the last time I looked at it. I consider Self to be a Smalltalk (just<br>
not a Smalltalk-80) and it can start with either a snapshot (its name<br>
for image) or with an empty world and load text files (possible because<br>
the source to bytecode compiler is included in the VM).<br>
<br></blockquote><div><br></div><div>I always wondered about how much performance is gained moving the all the Compiler infrastructure into the VM.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK)<br>
<br>
The MS-DOS port of Squeak had no GUI, just a command line prompt. That<br>
was also the case for GNU Smalltalk and Little Smalltalk.<br>
<br></blockquote><div><br></div><div>Didn't knew there was a DOS-only based Squeak. Any link out there to try?</div><div><br></div><div>For GST I should note there is an interesting project using GTK which provides a gst-browser, although cannot say if now is part of GNU Smalltalk.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> .- All implementations uses direct pointers, (GST?)<br>
<br>
The RoarVM for Squeak uses object tables. In fact, the lack of direct<br>
pointers in early implementations is what led to the use of #become:<br>
which complicated the adoption of direct pointers. VisualWorks has an<br>
indirection pointer in the header - see slide 7 of<br>
<br>
<a href="https://www.slideshare.net/esug/spur-a-new-object-representation-for-cog" rel="noreferrer" target="_blank">https://www.slideshare.net/esug/spur-a-new-object-representation-for-cog</a><br>
<br></blockquote><div><br></div><div>Thank you for the pointer, really informative presentation.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> - All implementations uses green threads. (VAST? MT?)<br>
<br>
I would say this was a side effect of patching the original Smalltalk,<br>
which was its own operating system (and so the idea of green thread<br>
doesn't apply) to run on top of Unix on commercial workstations. All the<br>
old code supposed the mix of cooperative and preemptive multithreading<br>
that breaks down if you have multiple native threads.<br>
<br>
Some from scratch Smalltalks copied this model while others (I am pretty<br>
sure it was the case for MT, as you mentioned) had their libraries<br>
written with native threads in mind.<br>
<br>
-- Jecel<br>
<br></blockquote><div><br></div><div>Thank you, added with credits to <a href="https://github.com/hernanmd/falsehoods_smalltalk">https://github.com/hernanmd/falsehoods_smalltalk</a></div><div><br></div><div>Cheers,</div><div><br></div><div>Hernán</div><div><br></div></div></div>