<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/23 Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2013-12-23, at 00:24, Craig Latta <<a href="mailto:craig@netjam.org">craig@netjam.org</a>> wrote:<br>
<br>
>> Why not strip the VM down as far as possible too, and pull in<br>
>> additional things when needed? Just enough VM to run a minimal<br>
>> Spoon. It doesn't have to be fast; it can pull in speedup methods<br>
>> as needed (or perhaps even swap itself for a fancier VM on the<br>
>> fly???).<br>
><br>
> Sure, that's the plan. I first asked someone to help with that in<br>
> 1998. It's not hard. No one has decided to devote time to it. Now's your<br>
> chance. :)<br>
<br>
</div>One thing would be to compile the VM without inlining. Another to remove the non-essential primitives, which have a fallback in image (*). Even more primitives could be made optional if the image had more fallbacks. Or if you knew the image wasn't going to use those primitives, which might be the case in Spoon. Also quite a bit of code is devoted to purely to optimizing - the method cache, at-caches etc.<br>
<br>
- Bert -<br>
<br>
(*) but don't be surprised if the fallback code suffers from bitrot. It is never executed on regular VMs with all the primitives in place. Having recently implemented a minimal VM I did discover those bugs ;)<br></blockquote>
<div><br></div><div>Yep, I saw at least one when I failed to change some primitive and made it accidentally fail.<br></div><div>For better testability, we could isolate the fallback code under a separate method, but that would consume a bunch of selectors and somehow be contradictory with a principle of economy - less is more.<br>
</div></div><br></div></div>