Looking briefly at this issue again, we might want to consider merging the CompiledMethodTrailer & AdditionalMethodState concepts. It seems a touch daft to have two mechanisms overlapping so much.

Of course, pretty much all the capabilities provided by the two could be done more cleanly by splitting methods up similarly to the version we did at Interval in '97/98; have a normal object with ivars for the literals, pragma, source info, bytecodes, etc.Yes, it would cost some memory . It would potentially save some time in GC. It would be simpler to extend things. Yada-yada.

Aside from that pipedream, it would probably be simplest to go for dropping the trailer bytes, and putting the info in the properties object. So that would mean every method would
replace the penultimate literal with a pointer to an AdditionalMethodState object, which would contain the usurped selector and some source access object. They also already include a pointer back to the method and then indexed values for pragmas etc. So that's 32 bytes for a bare case, or in a squeak 6 image a  megabytes & half since 1500 methods already have an AdditionalMethodState and we would 'save' the trailer bytes space. I'm not entirely sure why the back-pointer to the method is required after looking at the usage of it. Being able to dump that would save another ~half-MB.

What would this buy us? Simpler is almost always easier to understand and maintain, which is good. Storing the source would become a bit simpler since we could make appropriate classes for remote, in-image, in-image compressed, in-database, ask-another-image, etc.

A quick test of the size the system sources would be if kept in-image-compressed suggests ~11MB, which is rather better than the 52MB of the plain text file.  2MB of that is the 360 methods with more than 1024 bytes of zipped source, things like the sound of coffee cups clinking & car motors, plus some font stuff. 

A trivial hack to keep the sources in AdditionalMethodStates for every method, zipping as added, shows it can function. 

> On 2022-12-04, at 6:56 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> Some recent debugging handed me a reminder that we have several varieties of 'inboard source' in the system already, just not presently used and probably not complete.
> 
> Take  a look at CompiledMethod>>#getSourceFor:in:
> - it looks at the method properties, checking for a Dictionary with a #source entry
> - it checks the method trailer for tempNames, and if found, decompresses the names string and then decompiles the method and inserts those tempNames
> - it checks the trailer  for sourceCode that may be contained in one of four different ways, two of them being compressed strings in the trailer and I think the code in CompiledMethodTrailer>>#sourceCode fails to decompress them? The other two methods rely on methods that no longer exist in the image.
> - it checks if the trailer has a source pointer, and if not, decompiles the method with no assistance fro many temp names stuff
> - if there is a source pointer, that value is used to fetch the source from the file(s), and as a backup for the files not being there it repeats the bare decompile code.
> 
> I think we might be able to clean that up a bit.
> 
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Useful Latin Phrases:- Illiud Latine dici non potest = You can't say that in Latin.
> 
> 
> 
> 


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful Latin Phrases:- Illiud Latine dici non potest = You can't say that in Latin.