When is it time for a 1.0 feature freeze?

[Serg Kovrov]

Sean Kelly wrote:
> Serg Kovrov wrote:
>> Most desktop applications (like text editors, news readers, web 
>> browsers, etc) must coexist with each other. That is, to use memory 
>> wisely and give it back if it not needed anymore. This 'upper water 
>> mark' approach in GC is just not acceptable.
> 
> I think it depends on the application.  If an application behaves 
> consistently across their run cycle, there's no reason to return memory 
> to the OS because it will likely be needed again.  If an application 
> allocates a ton of memory, frees it, and never uses it again then what 
> you say is true.  Though in these cases the application could call 
> malloc/free for these one-time memory allocations as well.

I can't imagine an application that shouldn't free (return to OS) memory 
in runtime. Perhaps only really 'heavy' monopoly applications (like 
games, 3d modeling packages) and 'run and die' tools (like grep, less).

Other application that possibly could running unlimited time and process 
some significant amount of data, simply MUST return unused memory to OS.

For example web browser - user could open up to several tens of web 
pages simultaneously. Some maybe enormously big. If browser will no free 
memory consumed in such peak moments use will be forced to restart 
application (e.g. experience inconveniences) or will experience slowdown 
caused by swapping.

Same goes to any application working with arbitrary-sized data - image 
viewers, mail notificators, IDEs or text publishing tools, p2p clients 
or servers... Rally. As user, I don't want my everyday applications to 
hold peak memory, or restart them constantly. In the end i will chose 
other software, that will satisfy my habits.

I found it silly to shape behavior of an application by language (or it 
standard library) limitations.

If only programmer could have some control over GC, it would be just 
fine. For example to query GC's memory pool and decide to free some 
amount if it exceed some threshold. Walter, any comments on this?

-- 
serg.