<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Ken,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 17, 2021 at 8:13 AM <<a href="mailto:ken.dickey@whidbey.com">ken.dickey@whidbey.com</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"> <br>
You can help me out.<br>
<br>
I keep getting this wacky idea which does not seem to go away.  You can <br>
tell me what is wrong with it.<br>
<br>
OK.  Here it is:<br>
<br>
To get rid of PICs and dynamic method lookups, each Class knows <br>
selectors of methods it defines.  Each successful method definition is <br>
added not only to the method dictionary of the class, but copied down <br>
transitively to all subclasses, and their sub-subclasses, who have not <br>
defined a method with the same selector.<br>
<br>
At #DeepRehash time, _each_ method dictionary knows all of its selectors <br>
and creates a "perfect hash" function, or something close to it.<br>
<br>
So lookup is just into the specific method dictionary of the instance's <br>
class which yields the proper method (backstop method is DNU).  Never a <br>
miss.  No class hierarchy search for inherited methods.<br>
<br>
Memory is cheap these days, but selectors and compiled methods are <br>
mostly shared and the memory cost of method dictionaries is probably <br>
balanced out by elimination of PICS at the call sites.<br>
<br>
The UI tools need to keep some simple rules (e,g, transitively deleting <br>
methods from subclass method dictionaries), but these should be simple <br>
and obvious.<br>
<br>
The above seems simple enough, but nobody seems to be doing it.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I don't think no one is doing this.  I expect for example that the SqueakJS effort would explore this.</div><div class="gmail_default" style="font-size:small"><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">
<br>
Why not?<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">Speaking for myself when I did my threaded code version of BrouHaHa in the late '80's/early '90's I added copy down in the bytecode-to-threaded-code JIT so that self sends were statically bound.  t was an interesting experiment, and placed some additional constraints on become: if become changes any object's class then all activations must be visited and checked for validity, changing the current method to match the receiver if its class no longer matches the activation's copied down method.  This is easy to do with a threaded code JIT because there is a direct mapping between bytecode and threaded code, at least in my design, so that each byte of bytecode produced 8 bytes of threaded code (function and parameter, 32 bit arch).  But in general it can be difficult.  One wants to be able to take advantage of the static receiver, but if one does, then mapping activations between different versions of a copied down (& possibly optimized) method at any suspension point can become problematic.</div><div class="gmail_default"><font face="arial, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, sans-serif">When I joined Parc Place in '95 I got to know the world's best Smalltalk JIT at that time, Peter Deutsch's, HPS (Schiffman's context-to-stack mapper & <span style="color:rgb(0,0,0)">Jackson's and Ungar's</span><span style="color:rgb(0,0,0)"> GC).  This VM doesn't do copy-down and it influenced my work on the VM (I improved method caching, co-designed a new bytecode set and closure representation, designed a much improved context-to-stack mapping scheme, improved old space free space management, and did the 64-bit object representation which introduced class indices in headers rather than class pointers.  This experience from '95 through '06 heavily influenced my work on Cog and Spur.  Indeed the architectural idea for Sista/Scorch was inspired by performance analysis work Peter did, written up in the internal documentation for HPS.  Peter had introduced an in-line primitive bytecode so he could hand-generate static code to measure where the time is spent executing Smalltalk.</span></font></div><div class="gmail_default"><font face="arial, sans-serif"><span style="color:rgb(0,0,0)"><br></span></font></div><div class="gmail_default"><font face="arial, sans-serif"><span style="color:rgb(0,0,0)">With Sista/Scorch the entire policy for code management is moved up to the image, and is no longer a VM decision.  Scorch is freely able to copy-down and if it chooses to mediate become and class schema migration it has far more power to manage more aggressive optimization and code duplication than the VM.  So I'm looking forward to exploring copy-down in that context.  Of course, now that Clément has gone to Google, this work won't get done unless I can find collaborators.  And here I sound like a broken record.</span></font></div><div class="gmail_default"><font face="arial, sans-serif"></font></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">
<br>
Thanks much for insights!<br>
-KenD<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>