Comments on The deep heap: Is garbage collection a failed concept?

You might also want to take into account that the ...

2008-08-01T14:56:00.000-04:00

You might also want to take into account that the upcoming JVMs GC differently. They are practically throwing it into a constant low-priority subprocess, which tries to free a little from here and a little from there. The reason is that then you don't have to fall into complete GC cycle often (perhaps ever), which means you can usually allocate and guarantee that the allocation is fast.

adelle,

What's the issue? The encapsulatin...

2008-07-22T08:50:00.000-04:00

adelle,

What's the issue? The encapsulating class implements IDisposable and delegates to the instance member's Dispose(). There's even a pattern for this. What am I missing?

The problem with IDisposable, is how do you encaps...

2008-07-22T06:48:00.000-04:00

The problem with IDisposable, is how do you encapsulate an IDisposable object?

Excellent analysis! I tend to think that even in ...

2008-07-21T16:30:00.000-04:00

Excellent analysis! I tend to think that even in systems with hard real-time responsiveness constraints, a correctly implemented generational (or similar) GC is probably sufficient. A *lot* of research has gone into this area, and there's really no reason for modern garbage collection implementations to be "stop the world"-style. Yes, the system still has to slow down a bit during asynchronous

No, the need for determinism isn't being oversold....

2008-07-21T15:58:00.000-04:00

No, the need for determinism isn't being oversold. You're just not understanding the need. It's not about realtime requirements or responsiveness, but simply about determinism. After all, C# has the using block for just this reason. Other languages that rely on GC don't go that far, but the libraries certainly go out of their way to address the issue. Take ruby for instance. There's no end

While embedded systems running jet fighters need a...

2008-07-21T12:20:00.000-04:00

While embedded systems running jet fighters need all the responsiveness the underlying hardware allows, most other apps can tolerate some delays. By manually managing memory in exchange for extra determinism, these apps end up paying too much in terms of complexity for something they don't really need. My main point was that GC critics are overselling the need for application determinism.

If garbage collection were to be added to C++0x, d...

2008-07-21T11:02:00.000-04:00

If garbage collection were to be added to C++0x, destructors _would not_ be removed (that would be backwards incompatible), so RAII would still be possible. Instead presumably GC collected would simply not execute their destructor -- but stack allocated objects (used for the RAII pattern) would.

Also, that the majority of applications don't need real time response is not a good argument