Showing messages 1 through 7 of 7.

• Small embedded devices w/o GC
  2008-05-03 11:21:08 bboyes [Reply | View]
  
  We program industrial embedded Java devices such as JStamp/JStik, and C code on Atmel AVRs. The AVR C doesn't have any GC, or even malloc and free - it's all static. We get by fine actually, but these are relatively small, focussed low level apps. Deterministic behavior is essential. So is hard realtime performance. This comes for free with C and careful programming, even on a 16 Kbyte (code) and 1 KByte (data) device. Using I/O and timer interrupts we can create the equivalent of simple multi-threading apps with basically zero overhead.
  
  On the small embedded java devices (CLDC, with 2-4 MBytes Flash and 512 KBytes or more RAM) we can choose to use GC or not, and sometimes we have a single thread which does not use GC (and in fact can pre-empt it with ~1 usec context switch).
  
  So my point in recounting all that is that programming without GC or with limited GC is likely to be with us for a long time, at least on resource-constrained embedded devices. There GC is the exception, not the norm. And such devices run the machines and equipment all around us.

• Garbage Collections makes languages safer
  2008-04-30 11:15:16 xylifyx [Reply | View]
  
  The most important feature of garbage collection is that you can make the languages more safe. A memory model where pointers are always null or pointing to an object instance is impossible in a non trivial non garbage collected language.

• not a new one
  2008-04-28 18:32:03 dog [Reply | View]
  
  I'm ok w/ old non garbage collected languajes like C, C++, Pascal, etc..

  But why on earth would I consider a NEW language that is not garbage collected. That would be a step back in evolution.

• not a new one
  2008-04-28 22:56:48 jwenting [Reply | View]
  
  not necessarilly. For example for small devices with limited CPU and memory resources you may well want the leanness of C with the nice things of say Java or Ruby. So you'd end up with a new language that's a hybrid of the two, or something completely new, that offers direct memory management (maybe in addition to garbage collection, or with garbage collection available as an optional extra for platforms that aren't so limited in resources).

• GC is overrated
  2008-04-28 17:55:09 vhi [Reply | View]
  
  In both Java and C++, you need to be careful about the usage and the proper de-allocation of memory. I would say more so in Java than in C++!
  I have often felt that GCed languages gives us a false sense of security. I have too often been bowled out by innocuous looking inner classes keeping big objects within them. Now with the advent of Closures, it would be far too easy for us to get 'leaked'.
• GC is overrated
  2008-04-30 03:30:02 mayhem [Reply | View]
  
  I think you need to separate the "problems" with memory allocation. What you are talking about is performance problems, which may or may not exist in a GC'ed language depending on the implementation. To tackle a GC related performance problem, you can often avoid memory allocation inside performance critical code. The advantage C++ has over Java is that you can use stack allocation, which is basically free, inside performance critical code. Note that an advanced VM with full escape analysis can do this automatically for you, it's just that the JVM doesn't do this at the moment. So, the performance problems are not really related to GCs as a concept, rather to specific implementations of them.
  
  The other problem you mention is memory leaks. Here I would say having a GC is far superior to explicit memory deallocation. You can still have memory leaks in Java but they are basically caused by the same code pattern (listeners) and when you know about the problem you can quite easily avoid it (using weak references).
• GC is overrated
  2008-04-29 12:47:58 aberrant [Reply | View]
  
  GC eliminates an entire class of memory leaks. All you are left with are situation where you have a hard reference to an object that isn't needed. In C and C++ the pointer to the object/data can get lost. and then there is no way to free that memory. Java de-allocation is significantly less complicated.