<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Christoph, Hi All,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 7, 2020 at 10:12 AM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div>
<div dir="ltr">
<div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p>Hi Dave, hi all,</p>
<p><br>
</p>
<p>this sounds like a really interesting changeover. I have heard and read some rumors about Sista in the past, but I could not find any brief but complete summary of all the changes this will make to our existing Smalltalk system. So it would be great if you
could point us to some kind of changelog.</p></div></div></div></blockquote><div><br></div><div>The class comment for EncoderForSistaV1 gives a good introduction. Further information is available in the papers and presentations mentioned on <a href="http://squeak.org/research">squeak.org/research</a> But the key property is that, as a bytecode set, it does not affect semantics. It is an instruction set, not a new virtual machine.</div><div><ol class="gmail-bibliography" style="font-size:16px;box-sizing:border-box;margin-top:0px;margin-bottom:9.5px;list-style-type:none;color:rgb(51,51,51);font-family:Lato,Helvetica,Arial,sans-serif"><li style="box-sizing:border-box;padding:10px 0px"><span id="gmail-bera_2017_sso" style="box-sizing:border-box">Clément Béra, Eliot Miranda, Tim Felgentreff, Marcus Denker, and Stéphane Ducasse. <b style="box-sizing:border-box">“Sista: Saving Optimized Code in Snapshots for Fast Start-Up.”</b> In <i style="box-sizing:border-box">Proceedings of the 14th International Conference on Managed Languages and Runtimes</i>, 1–11. ManLang 2017. New York, NY, USA: ACM, 2017.</span><a href="http://doi.acm.org/10.1145/3132190.3132201" target="_blank" style="box-sizing:border-box;background-color:transparent;color:rgb(27,60,129);text-decoration:none">http://doi.acm.org/10.1145/3132190.3132201</a>.</li><li style="box-sizing:border-box;padding:10px 0px"><span id="gmail-bera_validation_2016" style="box-sizing:border-box">Clément Béra, Eliot Miranda, Marcus Denker, and Stéphane Ducasse. <b style="box-sizing:border-box">“Practical Validation of Bytecode to Bytecode JIT Compiler Dynamic Deoptimization.”</b> <i style="box-sizing:border-box">Journal of Object Technology</i> 15, no. 2 (2016): 1:1–26.</span> <a href="https://doi.org/10.5381/jot.2016.15.2.a1" target="_blank" style="box-sizing:border-box;background-color:transparent;color:rgb(27,60,129);text-decoration:none">https://doi.org/10.5381/jot.2016.15.2.a1</a>.</li></ol></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<p><span style="font-size:12pt">In what way will this affect your typical Squeak experience? </span></p></div></div></div></blockquote><div>You will be able to compile larger methods.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">What about performance? </span></p></div></div></div></blockquote><div>In an interpreter one may be able to find examples that are faster, but by very small percentages. Sista as a bytecode set on its own does not affect performance. However, once used by an adaptive optimizer (Clément's Scorch) performance should be in the 3x to 4x faster range. Of course, there is zero support and zero funding for this work. Clément is now at Google. I am attempting to self-fund this work for my PhD. I feel extremely let down by the entire community. This is excellent work but there is *zero*controbution from outside Clément and myself. Inria continue to crow about the PhartoVM (intellectual theft) but contribute nothing materially to improving the VM. The Potsdam folks continue to work on Graal, leaving this more interesting and more concentrative, all in Smalltalk work alone.</div><div><br></div><div>I feel very negative about the various communities' inability to support, and especially, join in this work. I find the position of Inria downright unethical; intellectual theft, deeply selfish. I find the lack of participation by the Potsdam folks very dispiriting.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">What about debugging/simulating code? </span></p></div></div></div></blockquote><div><br></div><div>No difference. It is a bytecode set.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">As someone who did not yet deal with any VM side effects, I would be interested to hear about the practical effects you can see when
playing around with Context & Compiler stuff. </span></p></div></div></div></blockquote><div><br></div><div>Again there should be no effects. There may be bugs lurking in the bytecode set specific code (see the class side of BytecodeEncoder, EncoderForv3, EncoderForV3PlusClosures and EncoderForSistaV1). The main source of bugs for the SistaV1 bytecode set is in its use of prefix bytecodes to extend the ranges of operands (see the class comment). The scheme is more complex than a non-prefix bytecode set, but I've been using the set for a year now and have fixed a few bugs over that time, the last known bug having been fixed in September of last year.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">I read about FullBlockClosure which appears to be kind of detached of its defining method. How will this change accessing thisContext home etc. from a FullBlockClosure, for example? </span></p></div></div></div></blockquote><div><br></div><div>It does not change semantics at all. It only changes where the bytecodes and literals for a block reside, not what their execution effects.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">I read Sista stores an optimization
cache between several runs. Where will this information be saved, at the image side or at the VM side?</span></p></div></div></div></blockquote><div>Scorch, the optimizer that exploits the unsafe primitives in the Sista bytecode set, optimizes by inlining unoptimized byte coded methods into byte coded methods which can contain unsafe primitives. Execution is faster due to the elimination of overheads (such as block creation) through inlining and through the use of unsafe primitives, proved safe by the Scorch optimizer, to perform arithmetic, object access, and instantiation. The optimized methods are stored in normal method dictionaries, shadowing their unoptimized source methods. So they persist in method dictionaries.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">Lots of questions, maybe someone can answer a few of them :-)</span></p></div></div></div></blockquote><div>I have a question.</div><div>Why is no one in the community joining me and Clément in trying to finish this work? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><div dir="ltr"><div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif"><p><span style="font-size:12pt">Best,</span><br></p>
<p>Christoph</p>
<div id="gmail-m_-8782135652603596362x_Signature">
<div id="gmail-m_-8782135652603596362x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper">
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%">
<div id="gmail-m_-8782135652603596362x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <<a href="mailto:squeak-dev-bounces@lists.squeakfoundation.org" target="_blank">squeak-dev-bounces@lists.squeakfoundation.org</a>> im Auftrag von David T. Lewis <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>><br>
<b>Gesendet:</b> Samstag, 7. März 2020 18:29:40<br>
<b>An:</b> <a href="mailto:squeak-dev@lists.squeakfoundation.org" target="_blank">squeak-dev@lists.squeakfoundation.org</a><br>
<b>Betreff:</b> Re: [squeak-dev] Switching to Sista bytecodes in trunk (was: The Inbox: Kernel-dtl.1310.mcz)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt">
<div>I will leave this in the inbox for a couple of days, and if there are<br>
no objections I will move it to trunk.<br>
<br>
Dave<br>
<br>
On Fri, Mar 06, 2020 at 07:43:29PM -0500, David T. Lewis wrote:<br>
> The Sista bytecode set enables important reasearch and development work.<br>
> Eliot and Clemont can explain better than me (apologies to Clemont Bera<br>
> for using my seven-bit character set on your name).<br>
> <br>
> Squeak 5.3 is released and we are starting the new release cycle, so it<br>
> is time to make Sista the default in trunk. Kernel-dtl.1310 (in the inbox)<br>
> activates Sista in the package postscipt.<br>
> <br>
> Dave<br>
> <br>
> On Sat, Mar 07, 2020 at 12:29:13AM +0000, <a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a> wrote:<br>
> > David T. Lewis uploaded a new version of Kernel to project The Inbox:<br>
> > <a href="http://source.squeak.org/inbox/Kernel-dtl.1310.mcz" target="_blank">http://source.squeak.org/inbox/Kernel-dtl.1310.mcz</a><br>
> > <br>
> > ==================== Summary ====================<br>
> > <br>
> > Name: Kernel-dtl.1310<br>
> > Author: dtl<br>
> > Time: 6 March 2020, 7:29:11.316779 pm<br>
> > UUID: 683e4e14-fc18-4d55-a776-eece91f579f5<br>
> > Ancestors: Kernel-mt.1309<br>
> > <br>
> > Change the Squeak default bytecode set to Sista in trunk.<br>
> > <br>
> > Add CompiledCode>>multipleBytecodeSetsActive: to optionally inform the VM that Sista is in use, see VMMaker.oscog-dtl.2711 and
<a href="http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html" target="_blank">
http://lists.squeakfoundation.org/pipermail/vm-dev/2020-January/032441.html</a>.<br>
> > <br>
> > Add CompiledCode>>useSista: convenience method for switching to and from Sista bytecodes.<br>
> > <br>
> > Package postscript activates the change to Sista bytecodes, which can be reversed by evaluating CompiledCode useSista: false.<br>
> > <br>
> > =============== Diff against Kernel-mt.1309 ===============<br>
> > <br>
> > Item was added:<br>
> > + ----- Method: CompiledCode class>>multipleBytecodeSetsActive: (in category 'method encoding') -----<br>
> > + multipleBytecodeSetsActive: aBoolean<br>
> > + "Inform the VM when multiple bytecode sets, typically the Sista bytecodes<br>
> > + in addition to the traditional V3 bytecode set, are now in use is this image.<br>
> > + The VM may use this information to update the image format number when<br>
> > + saving the image to the file system."<br>
> > + <br>
> > + <primitive: 'primitiveMultipleBytecodeSetsActive'><br>
> > + !<br>
> > <br>
> > Item was added:<br>
> > + ----- Method: CompiledCode class>>useSista: (in category 'method encoding') -----<br>
> > + useSista: useSistaEncoder<br>
> > + "Switch to or from the Sista bytecode encoder, and recompile the system<br>
> > + using that encoder. Assumes that Compiler recompileAll is working for the<br>
> > + existing system. Assumes that the currently available primary and secondary<br>
> > + bytecode encoders are EncoderForV3PlusClosures and EncoderForSistaV1.<br>
> > + This is a convenience method that must be updated as the available encoders<br>
> > + are changed."<br>
> > + <br>
> > + "CompiledCode useSista: true"<br>
> > + "CompiledCode useSista: false"<br>
> > + <br>
> > + | standardEncoder sistaEncoder activeEncoder |<br>
> > + standardEncoder := Smalltalk classNamed: #EncoderForV3PlusClosures.<br>
> > + sistaEncoder := Smalltalk classNamed: #EncoderForSistaV1.<br>
> > + activeEncoder := self preferredBytecodeSetEncoderClass.<br>
> > + useSistaEncoder<br>
> > + ifTrue: [sistaEncoder ifNil: [self error: 'EncoderForSistaV1 not present in this image'].<br>
> > + self preferredBytecodeSetEncoderClass: sistaEncoder.<br>
> > + activeEncoder ~= sistaEncoder<br>
> > + ifTrue: [(Smalltalk classNamed: #Compiler) recompileAll.<br>
> > + self multipleBytecodeSetsActive: true "VM should support Sista plus V3" ]]<br>
> > + ifFalse: [standardEncoder ifNil: [self error: 'EncoderForV3PlusClosures not present in this image'].<br>
> > + self preferredBytecodeSetEncoderClass: standardEncoder.<br>
> > + activeEncoder ~= standardEncoder<br>
> > + ifTrue: [(Smalltalk classNamed: #Compiler) recompileAll.<br>
> > + self multipleBytecodeSetsActive: false "VM needs to support V3 only" ]].<br>
> > + <br>
> > + !<br>
> > <br>
> > Item was changed:<br>
> > + (PackageInfo named: 'Kernel') postscript: '"Activate Sista bytecodes in the image"<br>
> > + <br>
> > + CompiledCode useSista: true.<br>
> > + '!<br>
> > - (PackageInfo named: 'Kernel') postscript: '"below, add code to be run after the loading of this package"<br>
> > - "Since Kernel-eem.1198 redefines LargePositiveInteger hash,<br>
> > - rehash all hashed collections that contain hashed large integers."<br>
> > - HashedCollection allSubclassesDo:<br>
> > - [:c| | f |<br>
> > - f := (c includesBehavior: Set)<br>
> > - ifTrue: [[:i| i]]<br>
> > - ifFalse: [[:i| i keys]].<br>
> > - c allInstancesDo:<br>
> > - [:h|<br>
> > - ((f value: h) detect: [:e| e isInteger and: [e class ~~ SmallInteger]] ifNone: nil) ifNotNil:<br>
> > - [h rehash]]]'!<br>
> > <br>
> > <br>
> <br>
<br>
</div>
</span></font>
</div>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div></div>