i made a program that frequently uses lots of dynamic memory, and set a WM_TIMER message to call gc.fullCollect(). but it never seems to actually free any memory according to the task manager.

imr1984 wrote:

> i made a program that frequently uses lots of dynamic memory, and set a WM_TIMER
> message to call gc.fullCollect(). but it never seems to actually free any memory
> according to the task manager.
> 

I think it just reclaims the memory to a free pool, allowing you to reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).

-- 
Christopher E. Miller

Vathix wrote:

<snip>
> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).

So, which little-known compiler has this?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> Vathix wrote:
>
> <snip>
>
>> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).
>
>
> So, which little-known compiler has this?
>
> Stewart.

I think that most compilers do this (including C++).  The only one I can think of that frees memory back to the OS is Eiffel.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Stewart Gordon wrote:
>> Vathix wrote:
>> <snip>
>>> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).
>>
>> So, which little-known compiler has this?
> 
> I think that most compilers do this (including C++). 

I said "has this".  As in the misnamed std.gc.getStats.

> The only one I can think of that frees memory back to the OS is Eiffel.

You mean I'll have to write in this if I want my program to be able to let go of some memory so that other programs can do their business?

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> J Anderson wrote:
> 
>> Stewart Gordon wrote:
>>
>>> Vathix wrote:
>>> <snip>
>>>
>>>> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).
>>>
>>>
>>> So, which little-known compiler has this?
>>
>>
>> I think that most compilers do this (including C++). 
> 
> 
> I said "has this".  As in the misnamed std.gc.getStats.
> 
>> The only one I can think of that frees memory back to the OS is Eiffel.
> 
> 
> You mean I'll have to write in this if I want my program to be able to let go of some memory so that other programs can do their business?
> 
> Stewart.
> 

The OS might swap the memory out (as that memory is not being accessed ?) so that other programs get it, but I'm no expert on how this occurs. That doesn't really help, does it :p

-- 
Christopher E. Miller

Stewart Gordon wrote:

> J Anderson wrote:
>
>> Stewart Gordon wrote:
>>
>>> Vathix wrote:
>>> <snip>
>>>
>>>> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).
>>>
>>>
>>> So, which little-known compiler has this?
>>
>>
>> I think that most compilers do this (including C++). 
>
>
> I said "has this".  As in the misnamed std.gc.getStats.
>
>> The only one I can think of that frees memory back to the OS is Eiffel.
>
>
> You mean I'll have to write in this if I want my program to be able to let go of some memory so that other programs can do their business?
>
> Stewart.
>
If the memory is not being used it'll probably be swapped out to a page file on the hardrive.

-- 
-Anderson: http://badmama.com.au/~anderson/

Stewart Gordon schrieb:

> You mean I'll have to write in this if I want my program to be able to let go of some memory so that other programs can do their business?

Eiffel won't help either, since it would work on some C runtime anyway. :>

Walter promised that D's GC would return memory to OS page-wise as it gets free.

-eye

Vathix wrote:

> Stewart Gordon wrote:
> 
>> J Anderson wrote:
>>
>>> Stewart Gordon wrote:
>>>
>>>> Vathix wrote:
>>>> <snip>
>>>>
>>>>> I think it just reclaims the memory to a free pool, allowing you to  reuse it without allocating more from the OS. I do the same WM_TIMER thing sometimes, and you can get GC stats from std.gc.getStats() (not standard).
>>>>
>>>>
>>>>
>>>> So, which little-known compiler has this?
>>>
>>>
>>>
>>> I think that most compilers do this (including C++). 
>>
>>
>>
>> I said "has this".  As in the misnamed std.gc.getStats.
>>
>>> The only one I can think of that frees memory back to the OS is Eiffel.
>>
>>
>>
>> You mean I'll have to write in this if I want my program to be able to let go of some memory so that other programs can do their business?
>>
>> Stewart.
>>
> 
> The OS might swap the memory out (as that memory is not being accessed ?) so that other programs get it, but I'm no expert on how this occurs. That doesn't really help, does it :p
> 

There does tend to be an overall limit to how much an OS will allocate (in my case 1.5gb, 512mb ram + 1gb swap), swap and all. It could be handy to have something to call when one explicitly does want to free memory back to the OS, not just to the GC. Let's say I ran a program that used 1.2gb at one point for some scientific calculation, and then for the next bit only really needs 50mb, but lots and lots of CPU time... Would 200mb of my actual physical memory continue to be allocated to this program? That would be a little counter-intuitive, imo.

AFAIK (from the D docs) D allows explicitly 'free'ing of objects, ie the freeing of objects that will call the object's destructors *at that time* and not wait for the GC to plod along at its convenience... Which is a very useful feature if its absolutely imperative to free a resource at that given time. I really liked this compromising attitude, where the GC will sort you out most of the time, but if you tell the GC you know what you want, it'll let you have your way. In this case, with memory allocation, if the GC does in fact not release its RAM back to the OS at any time, wouldn't it make some sense to have a method of explicitly telling it to?

Cheers,
Sigbjørn Lund Olsen
(But I May Be Wrong)