Perhaps you need to run deterministically without a stop-the-world garbage collector? A) the world is bigger than simple web applications and B) some of us have been doing this for a long time.

I wasn't talking about web applications, and modern garbage collectors are not stop-the-world.

Not to mention ... stop-the-world garbage collectors have a good reason for doing what they do. They are defragmenting the memory. You get that for free, when in C++ you would have to deal with hell if your app is doing lots of allocations ... see the shit the Firefox devs had to go through to alleviate the problems of heap fragmentation, and its still a problem.

Ah, but what, you're using both managed code (C#) and unmanaged code (C++) in the same address space, doing memory intensive work using third party proprietary C++ code that does lots of small allocations?

In 32-bit land, it's welcome to OutOfMemoryException because managed code can't allocate a big enough chunk when returning to C#.

No free lunch :)

Either recycle processes often or reserve big enough contiguous chunks in managed code before calling out to the bad C++ code, no amount of good citizenship in managed code will stop the poorly written native code from fragmenting the hell out of your address space.

Unfortunately we don't all have the luxury of rewriting all our code in the trendy language du jour.

Can you give an example of stop-the-world garbage collection?

I've experienced problems with java's concurrent mark and sweep collector. It will stop the world, two times, but two much shorter times than a non-concurrent mark and sweep. So it is definitely an improvement in the duration of the stop-the-world.

The problem tends to be that you need to tune it, and even as you have tuned it, you can not promise that under special condition it will fall back to a more primitive collector since the optimality it was tuned for doesn't hold anymore.

I would never argue giving up garbage collection entirely because of these failure scenarios. I would much rather look at moving some critical part of the code out to a language with manual allocation, and let it perform the latency-sensitive bits.

Another mid-ground is to have separate isolate processes (heaps really) that can be stop-the-world collected without blocking each other. Erlang makes great use of this to accomplish "soft realtime", among other things.

Javascript... Yes, even V8.

Side rant: it's part of the reason that my Palm Pre will sometimes just hang for a second at the worst times, such as when I go to answer the phone. :(

A simple mark & sweep or stop & copy GC. Collectors which are incremental (work in small steps, not one full pass at a time) and/or generational (using several smaller generations, which are collected individually) break up GC pauses into something less disruptive.

For a good overview, read "Uniprocessor Garbage Collection Techniques" by Paul Wilson (check google scholar). Richard Jones's _Garbage Collection: Algorithms for Automatic Dynamic Memory Management_ is more in depth.

If you meant actually existing stop the world GC, the server GC in Microsoft's CLR stops all threads on a processor to do GC.

Try allocating a very large chunk of memory using a high-level language with garbage collector. It's not always about collection.

Why would you allocate a large chunk of memory, when you are using a garbage collected language?

There may be reasons to want to mix manual and automatic memory management. If you want to do that, there are language that support it. Like D.

Not necessarily allocating very large chunks in bulk but umm... Allocating nodes for a million nodes of a graph and subsequently processing them. Java JVM fragments memory heavily. En

> And for application-level programming, why would you chose a language without a garbage-collector?

Because your code uses some finite resources other than memory, and you don't want the ability to forget to release said resources when you're done with them and they go out of scope.

Why should memory management related to managing other resources. Anyway, you might be interested in The Haskell Disciplined Disciple Compiler (http://www.haskell.org/haskellwiki/DDC) which lets you statically encode resource management rules. (And of course spots garbage collection for memory.)

Your objects contain/use various resources, such as memory, file descriptors, mutexes, etc. The way to reclaim any of these is to destroy the object, which lets you reclaim all of them. So memory management is very much tied to other resource management, since they both involve the same thing (deciding when to destroy objects you no longer need). Unfortunately not all resources can be collected equally lazily, so memory-centric GC schemes that ignore the requirements of other resources tend to get in the way (and make you do using(){...} or try/finally to make sure your files are closed, instead of allowing for RAII).

> The way to reclaim any of these is to destroy the object, which lets you reclaim all of them.

I asked why one should mix management of resources, and you answer that one should mix management of resources. But I still don't know why?

It's more that how the hell do you unmix them (any why would you bother, anyway)?

How to unmix: Just e.g. close your files explicitly, but let the memory of the data structures that represent your files be garbage collected normally.

For patterns of usage similar to RAII, Common Lisp uses unwind-protect. I already mentioned Disciplined Disciple Compiler that extends Haskell to give static guarantees for following certain rules for resource management.

Why would you bother: RAII only covers some cases for resource management, and most garbage collectors can take an arbitrary long time to collect an object that's no longer reachable. Which is fine for memory, because memory is fungible, but the attached resources, say mutexen, are not necessarily fungible.