> On 2022-12-24, at 1:03 PM, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> 
> No, no, no and no!  This works for HIT only implementations but it is awful for interpreted implementations. One has to traverse two objects to get to the bytecode, not one.

Don't care for the purpose of thinking about this. As best I can recall it actually didn't make any noticeable difference when we did it at Interval but then again, machines were what, 1% of modern performance back then? But I'm not about to mess with deep VM code to try it out again. I still have the scars from the first time, thank you very much.


> It’s a lot of space to give up when the trailer implementation works.

Again, not very interesting *at this point*. After all, the default image has a huge amount of stuff that ought to be removed if one is interested in saving memory for a server usage pattern. EToys, the games... 

Also, using the trailer bytes stuff means recompiling every method and doing a mass become, which right now blows away the ARM64 VM with extreme prejudice, not even in #condenseSources :-( I'll see if the very latest VM build solves that. Just FYI the offending method is attached.


>> A trivial hack to keep the sources in AdditionalMethodStates for every method, zipping as added, shows it can function. 
> 
> That’s not the thing to prototype. Extending the ClassBuilder and bytecode compiler do that one can create subclasses of CompiledMethod whose inst vars live in AMS subclasses is the thing to prototype.

Not sure why I'd need to do that when the AMS class is perfectly happy to have a #source property as-is (See CompiledMethod>>#getSourceFor:in:)

Obviously there's some compiler related changes needed to make sure the source for new methods gets set properly and so on. Not seeing that as too tricky, so far anyway. The messy bit is most likely the array of tool related code that does assume source from files and so on. That alone might make it impractical to change anything.

My aim is to see if we could have a system where all the code in use is in the image. Any change to a method would still be logged, assuming the changes file is in use. I think for most server type cases we wouldn't have changes being logged in the normal fashion, though perhaps by some means along with general logging. It should help with forking images on a server for example, and that is definitely a matter of some interest.

Maybe none of it will work. Maybe it's Maybelline.

tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SmalltalkImage-inboardSources.st
Type: application/octet-stream
Size: 1856 bytes
Desc: not available
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20221224/5a7f39ef/attachment.obj>
-------------- next part --------------

--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: BBL: Branch on Burned out Light