"ABothe" <info@asdf.com> wrote in message news:i1hf3h$7sd$1@digitalmars.com...
> So there isn't any other method than calling C's free(); or malloc
> (); ?

GC.minimize() should do it:

http://www.digitalmars.com/d/2.0/phobos/std_gc.html

If it doesn't, then there's probably something holding on a reference to it (like the LRU cache Steven mentioned), or something that the GC mistakenly thinks is a reference to it.

-------------------------------
Not sent from an iPhone.

"Nick Sabalausky" <a@a.a> wrote in message news:i1iaan$1nbe$1@digitalmars.com...
> "ABothe" <info@asdf.com> wrote in message news:i1hf3h$7sd$1@digitalmars.com...
>> So there isn't any other method than calling C's free(); or malloc
>> (); ?
>
> GC.minimize() should do it:
>
> http://www.digitalmars.com/d/2.0/phobos/std_gc.html
>
> If it doesn't, then there's probably something holding on a reference to it (like the LRU cache Steven mentioned), or something that the GC mistakenly thinks is a reference to it.
>

But, in a GC'ed environment, you shouldn't normally be trying to release memory back to the OS every time you delete something. In most cases, the GC deliberately saves freed memory to return it back to you the next time you allocate. So if you want to see whether or not you're *really* leaking, try something more like this:

while(true)
{
    byte[] asdf=new byte[50_000_000];
    GC.free(cast(void*) asdf.ptr);
}

Then monitor the memory usage reported by the OS. If it keeps climbing higher and higher and higher, then something's going wrong. If it stays pretty much constant, then everything's working correctly.

FeepingCreature:
> On 13.07.2010 12:28, ABothe wrote:
> > So there isn't any other method than calling C's free(); or malloc
> > (); ?
> 
> That's how it is.

But you can build some abstraction by yourself, for example inside a struct you can keep the pointer to a memory block in the C heap, and in the ~this() of the struct you can put the free(). Then D has to give you a way to disallow the "new" on this struct, to be sure its destructor is called when it goes out of scope (or the object it's contained into gets deallocated).

Bye,
bearophile

On 07/13/2010 03:36 PM, bearophile wrote:
> FeepingCreature:
>> On 13.07.2010 12:28, ABothe wrote:
>>> So there isn't any other method than calling C's free(); or malloc
>>> (); ?
>>
>> That's how it is.
>
> But you can build some abstraction by yourself, for example inside a struct you can keep the pointer to a memory block in the C heap, and in the ~this() of the struct you can put the free(). Then D has to give you a way to disallow the "new" on this struct, to be sure its destructor is called when it goes out of scope (or the object it's contained into gets deallocated).
>
> Bye,
> bearophile

Also refer to RefCounted:

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/typecons.d#L1991

Highly recommended.


Andrei

So it's not planned by you or Walter to let the GC be able to free
some memory? I mean this would be very helpful and would make
large programs possible
(Especially those ones are often working with a huge data
amount...think of running that program for a while...the memory
consumption would be enormously high:-/ and mess up the whole
system)

ABothe wrote:
> So there isn't any other method than calling C's free(); or malloc
> (); ?
	Note that there is no guarantee that C's malloc/free will return
the memory to the OS either (*). The only way to be sure that the
memory will be returned is to call mmap/munmap (or their equivalent
on whatever OS you're using).

(*) Most malloc implementations allocate large chunks of memory using mmap, which can return the memory to the OS, but they allocate small chunks with sbrk, which can't. As proof, see the attached C code which prints:

At the beginning:
VmSize:	    3872 kB
After allocating the memory:
VmSize:	   36608 kB
After releasing the memory:
VmSize:	   36608 kB


		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

ABothe, el 13 de julio a las 23:20 me escribiste:
> So it's not planned by you or Walter to let the GC be able to free
> some memory? I mean this would be very helpful and would make
> large programs possible
> (Especially those ones are often working with a huge data
> amount...think of running that program for a while...the memory
> consumption would be enormously high:-/ and mess up the whole
> system)

gc.minimize() is supposed to do that. But if you really need to work with huge datasets, I'd recommend to do manual memory management anyways, because of the current limitations of the GC.

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Hoy estuvimos en el museo de antropología, pero yo voy a volver
para estar por lo menos un día ahí adentro... es una locura, como Disney pero
de indigenas
	-- Carla Lucarella (10/2008 contando de su viaje a México)

On Tue, 13 Jul 2010 02:44:49 +0300, ABothe <info@alexanderbothe.com> wrote:

> Hi everyone,
>
> I don't know if it's a bug or not .. but D or at least its GC doesn't want to
> free my allocated stuff! Also when I 'disable' the GC via GC.disable(); it won't free it :-/

Alex, please have a look at the module I posted to D.announce. It allows working with unmanaged memory without having to worry about manual deallocation, etc.

For example:

import std.stdio;
import std.gc;
import data;

void main()
{
	Data d = new Data(50_000_000);
	readln(); // check my memory usage now
	d = null;
	fullCollect();
	readln(); // check my memory usage now
}

You can get my module from here: http://github.com/CyberShadow/data.d

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net