[Vm-dev] Copy Down to avoid Looking Up

nabble.42 at klix.ch nabble.42 at klix.ch
Wed Mar 17 18:31:19 UTC 2021


Hi Ken,

I am by no means a VM expert, but this idea can
be enhanced further:

Let's generate consecutive
numbers for all the symbols used as message selectors then this "perfect 
hash" degenerates
to an array with pointers to the compiled
method. Let's also ignore
-- for the sake of simplicity --
symbols that are garbage collected;
the holes occurring can simply be filled
by some sort "free-list-algorithm.

Now you have something the C++ programmer knows
really well: A virtual function table.

I have no clue whether those VFTs will help.


Just my 0.01€.


Best Regards,

Gerald



On 2021-03-17 16:13, ken.dickey at whidbey.com wrote:
> 
> You can help me out.
> 
> I keep getting this wacky idea which does not seem to go away.  You can 
> tell me what is wrong with it.
> 
> OK.  Here it is:
> 
> To get rid of PICs and dynamic method lookups, each Class knows 
> selectors of methods it defines.  Each successful method definition is 
> added not only to the method dictionary of the class, but copied down 
> transitively to all subclasses, and their sub-subclasses, who have not 
> defined a method with the same selector.
> 
> At #DeepRehash time, _each_ method dictionary knows all of its selectors 
> and creates a "perfect hash" function, or something close to it.
> 
> So lookup is just into the specific method dictionary of the instance's 
> class which yields the proper method (backstop method is DNU).  Never a 
> miss.  No class hierarchy search for inherited methods.
> 
> Memory is cheap these days, but selectors and compiled methods are 
> mostly shared and the memory cost of method dictionaries is probably 
> balanced out by elimination of PICS at the call sites.
> 
> The UI tools need to keep some simple rules (e,g, transitively deleting 
> methods from subclass method dictionaries), but these should be simple 
> and obvious.
> 
> The above seems simple enough, but nobody seems to be doing it.
> 
> Why not?
> 
> Thanks much for insights!
> -KenD


More information about the Vm-dev mailing list