Jump to page: 1 2 3
Thread overview
Garbage Collection
Aug 16, 2001
Warren Baird
Aug 16, 2001
Angus Graham
Aug 16, 2001
Walter
Aug 17, 2001
Will Hartung
Sep 06, 2001
Russ Lewis
Sep 07, 2001
Walter
Sep 07, 2001
Russ Lewis
Sep 07, 2001
Axel Kittenberger
Sep 08, 2001
Walter
Sep 07, 2001
Russ Lewis
Sep 08, 2001
Walter
Aug 17, 2001
Michael Gaskins
Aug 17, 2001
Sheldon Simms
Aug 17, 2001
Kent Sandvik
Aug 25, 2001
Roland
Aug 25, 2001
Dan Hursh
Aug 25, 2001
Florian Weimer
Oct 23, 2001
Sean L. Palmer
Oct 28, 2001
Walter
Aug 17, 2001
Russ Lewis
Aug 18, 2001
Walter
August 16, 2001
I apologize if this has been addressed somewhere I haven't read everything on this news server yet...

In general I like the sound of D a lot - One of the things I liked about Java was getting rid of a lot of the annoying and troublesome features of C++.

However, I come from a background of doing scientific visualization software for computational fluid dynamics, and one of the things that made Java totally useless was the garbage collection model it used. When you are tossing about 100Mb arrays of data - you really need a way to say "I'm done with this - deallocate it NOW".

Java's GC tends (or tended, I haven't looked at it in a year or so) to only run when things are idle, so it was really easy to run out of memory if you were doing a lot of intensive work.

I'm not saying that GC is a bad thing, just that it would be great if there was a way of convince the GC to run at specified intervals, to explicitly indicate that it should run NOW, or to explicitly deallocate a specified block of memory...

Are there any plans to provide this kind of functionality?

Warren

August 16, 2001
"Warren Baird" <warren@127.0.0.1> wrote in message
>
> <snip> When
> you are tossing about 100Mb arrays of data - you really need a way to
> say "I'm done with this - deallocate it NOW".
>

http://www.digitalmars.com/d/class.html:

"The program can explicitly inform the garbage collector that an object is no longer referred to (with the delete expression), and then the garbage collector calls the destructor immediately, and adds the object's memory to the free storage."


August 16, 2001
Yes, you are absolutely right. D has a "delete" operator, that explicitly
tells the gc that this memory can be free'd now and there's no need to wait
until the next gc cycle. It'd be up to the programmer, however, to guarantee
that there'd be no dangling references to the memory, so it isn't perfect
:-(
 -Walter

"Warren Baird" <warren@127.0.0.1> wrote in message news:3B7C306D.1060907@127.0.0.1...
> I apologize if this has been addressed somewhere I haven't read everything on this news server yet...
>
> In general I like the sound of D a lot - One of the things I liked about Java was getting rid of a lot of the annoying and troublesome features of C++.
>
> However, I come from a background of doing scientific visualization software for computational fluid dynamics, and one of the things that made Java totally useless was the garbage collection model it used. When you are tossing about 100Mb arrays of data - you really need a way to say "I'm done with this - deallocate it NOW".
>
> Java's GC tends (or tended, I haven't looked at it in a year or so) to only run when things are idle, so it was really easy to run out of memory if you were doing a lot of intensive work.
>
> I'm not saying that GC is a bad thing, just that it would be great if there was a way of convince the GC to run at specified intervals, to explicitly indicate that it should run NOW, or to explicitly deallocate a specified block of memory...
>
> Are there any plans to provide this kind of functionality?
>
> Warren
>


August 17, 2001
Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've just started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC routines should still be implemented, but it would be nice to also be able to initiate the process manually.

Michael Gaskins
Computer Science Dept, Clemson University
Undergraduate (Junior)

"Warren Baird" <warren@127.0.0.1> wrote in message news:3B7C306D.1060907@127.0.0.1...
> I apologize if this has been addressed somewhere I haven't read everything on this news server yet...
>
> In general I like the sound of D a lot - One of the things I liked about Java was getting rid of a lot of the annoying and troublesome features of C++.
>
> However, I come from a background of doing scientific visualization software for computational fluid dynamics, and one of the things that made Java totally useless was the garbage collection model it used. When you are tossing about 100Mb arrays of data - you really need a way to say "I'm done with this - deallocate it NOW".
>
> Java's GC tends (or tended, I haven't looked at it in a year or so) to only run when things are idle, so it was really easy to run out of memory if you were doing a lot of intensive work.
>
> I'm not saying that GC is a bad thing, just that it would be great if there was a way of convince the GC to run at specified intervals, to explicitly indicate that it should run NOW, or to explicitly deallocate a specified block of memory...
>
> Are there any plans to provide this kind of functionality?
>
> Warren
>


August 17, 2001
Michael Gaskins wrote:

> Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've just started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC routines should still be implemented, but it would be nice to also be able to initiate the process manually.

How about using "delete" alone, without any following parameter, for this purpose?

-BobC


August 17, 2001
Im Artikel <9li8re$npb$1@digitaldaemon.com> schrieb "Michael Gaskins" <mbgaski@clemson.edu>:

> Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've just started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC routines should still be implemented, but it would be nice to also be able to initiate the process manually.

I find this to be a much better solution that allowing the programmer to throw away individual memory blocks regardless of who else might be referencing them.

-- 
Sheldon Simms / sheldon@semanticedge.com
August 17, 2001

Walter wrote:

> Yes, you are absolutely right. D has a "delete" operator, that explicitly
> tells the gc that this memory can be free'd now and there's no need to wait
> until the next gc cycle. It'd be up to the programmer, however, to guarantee
> that there'd be no dangling references to the memory, so it isn't perfect
> :-(
>  -Walter

This disrupts the whole safety given by the GC. Let's assume for a while that your GC has some way of telling: this is the last reference to the object (easy in reference-counting schemes, more difficult otherwise). Then doing delete when you are not the last reference could be flagged as a programming error.

Alternatively, delete could simply be a mean to remove a reference to the object. If there are no other references, then you are guaranteed that the object is freed immediately. If there are other references, then the object remains in memory, but your own reference is removed.

Both approaches are safer, which is a whole point of a GC. Again, a GC without safety is close to worthless. It's a bit like saying: I have a GC, but it crashes if I have a null pointer in my program.


Christophe

August 17, 2001
"Christophe de Dinechin" <descubes@earthlink.net> wrote in message news:3B7D3073.950BD33@earthlink.net...
> Walter wrote:
>
> > Yes, you are absolutely right. D has a "delete" operator, that
explicitly
> > tells the gc that this memory can be free'd now and there's no need to
wait
> > until the next gc cycle. It'd be up to the programmer, however, to
guarantee
> > that there'd be no dangling references to the memory, so it isn't
perfect
> > :-(
> >  -Walter
>
> This disrupts the whole safety given by the GC.

*snip*

Yes, this is like "Look, we have the potential slowdowns of GC plus the instability of dangling memory references! Whee!" Sounds like the worse of both worlds to me.

Now, in theory, as Christopher mentioned,the delete can be a "smart" delete, but assigning an object reference to NULL could be "just as smart".

But I think adding this capability gives false hope to the users. "How come my code is slow, I don't use GC at all, just 'delete'?" Why, it's slow for the same reason it would be slow in other non-GC'd languages. Memory management is a lot more than throwing "new" and "delete" around willy nilly. Garbage Collectors add the ability to recompact and reorganize memory as well.

So, I think that you may want to allow the program to be more converstational with the GC so that you might be able to do things like what alloca (The GNU stack allocator) (i.e. I'm about to allocate a bunch of real short term stuff that you can kill en masse when I'm done...).

Another complaint most people have is that they've grown accustomed to using C++ destructors, which in many GC'd languages may never fire. In Java that tends to be done in 'finally' blocks.

/Will




August 17, 2001
Warren Baird wrote:

> I apologize if this has been addressed somewhere I haven't read everything on this news server yet...
>
> In general I like the sound of D a lot - One of the things I liked about Java was getting rid of a lot of the annoying and troublesome features of C++.
>
> However, I come from a background of doing scientific visualization software for computational fluid dynamics, and one of the things that made Java totally useless was the garbage collection model it used. When you are tossing about 100Mb arrays of data - you really need a way to say "I'm done with this - deallocate it NOW".
>
> Java's GC tends (or tended, I haven't looked at it in a year or so) to only run when things are idle, so it was really easy to run out of memory if you were doing a lot of intensive work.
>
> I'm not saying that GC is a bad thing, just that it would be great if there was a way of convince the GC to run at specified intervals, to explicitly indicate that it should run NOW, or to explicitly deallocate a specified block of memory...

I agree that it would be good to have some way to tell it "do garbage collection now."

The simplest way to deal with things would be to run the garbage collection routine any time that the operator new fails.  Inside that operator, if it fails once, it should run the garbage collector and then retry.  If it still fails, then throw an out of memory exception.

I can see where the programmer might want to schedule garbage collection manually, but I think that this should be as automated a process as possible.

Another idea: what about something (perhaps defined at compile time, perhaps a runtime parameter) that would automatically call the garbage collector after a certain number of releases of references?

August 17, 2001
"Michael Gaskins" <mbgaski@clemson.edu> wrote in message news:9li8re$npb$1@digitaldaemon.com...
> Actually I think it would be be very benificial if we could just have a function call (forgive me if it's called something different in D, I've
just
> started looking into the project) to force the garbage collector to run. This way the programmer could periodically "clean out the memory" at oppurtune times in the programs execution cycle.  The automatic GC
routines
> should still be implemented, but it would be nice to also be able to initiate the process manually.

For real-time intensive tasks, if one could also enforce that the GC should not run for a certain section, maybe that would also help out. It's true it would cause performance problems later, but it gives more power in case there's a section in the code where GC would cause problems, especially with timing issues and such. --Kent



« First   ‹ Prev
1 2 3