Size limit to changes
DanI at wdi.disney.com
Tue Aug 11 16:55:33 UTC 1998
>I don't remember if this has been mentioned:
>Since CompiledMethod stores the position of its source in three bytes, once the changes file (or sources) exceeds 16 meg, the CompiledMethod will no longer be able to recover its source.
For the record, here are the recommended strategies for dealing with this limit:
1. Condensing changes will, of course, prolong the time before this limit is reached.
2. Condensing all sources into a new base sources file will allow you to move a lot of the changes into the sources file, thus reducing the base size of the changes file.
3. The source code mechanism is set up to provide up to 4 source files of 16M each, but it would take some new code to provide a graceful transisiton into multiple changes files. While it seemed like a good idea in 1980, it's probably not worth the complexity of juggling 4 files.
4. The two bits that currently provide for 4 source files could be reinterpreted to provide either
a) one 16M base source file and one 48M changes file, or
b) one 32M base source file and one 32M changes file.
5. Go to a 4-byte source pointer and not give it any more thought.
I am interested in hearing from serious users of Squeak regarding how they would most like to see in this area. Methinks that option (4b) above should be adequate for most realistic uses. The two-file approach has stood the test of time, and 32M is about 6 times the size of the current entire Squeak release. It would be a relatively simple change to make if there is agreement about this.
More information about the Squeak-dev