[squeak-dev] [Cuis] 32Mb Sources limit

Juan Vuletich juan at jvuletich.org
Mon Feb 15 02:26:22 UTC 2010


keith wrote:
>
> On 14 Feb 2010, at 21:22, Igor Stasenko wrote:
>
>> On 14 February 2010 16:13, keith <keith_hodges at yahoo.co.uk> wrote:
>>> Juan,
>>>
>>> Do you have any thoughts you would like to share about on what you 
>>> want do
>>> about this issue?
>>>
>>> I wonder if there is any documentation on the 3.11-trunk 
>>> implementation of
>>> method trailers? Does it meet the simplicity criteria for Cuis?
>>>
>>> I have working a StandardSourceFileArrayPlus which multiplies the 
>>> existing
>>> sourceFile pointer by 16 giving a theoretical sources/changes limit of
>>> 512Mb. This seems to work ok as an experiment.
>>>
>>
>> New trailers imposing no limit to a file size. It can be of any size.
>>
>>> Keith
>
> Thanks Igor,
>
> I understood that bit.
>
> My question is whether Juan has an opinion on your implementation with 
> regards simplicity/elegance/economy and his goals for Cuis.

Not yet. I need to actually look at it.

> My use of Cuis is always building from the base start image so I am 
> unlikely to hit the limit any time soon, however the limit can be 
> extended to 512MB with about 4 methods, once the System-Sources 
> refactoring I am working on is complete (i.e. moving references to 
> RemoteString into the System-Sources package).

I'd like to see that refactoring, and to load it into Cuis. Please tell 
when it is complete.

> It may be simpler to use my solution, however it might be useful for 
> you to give us some indication of what the trade-offs are. Memory 
> overhead etc.
>
> The cost of my solution is that the sources/changes files bloat by 
> roughly 0.03% as records are padded to be saved on 16 byte boundaries.

That's zero cost to me. Besides 512Mb sounds like enough not to worry 
about it anymore. On the other hand, loading Method Trailers could have 
some other uses, and it would mean syncing CompiledMethod with trunk, 
which is a good thing.

> regards
>
> Keith

Cheers,
Juan Vuletich



More information about the Squeak-dev mailing list