Solar wrote:
Give me some time to brush up my Java skills (been busy with C++ the last four years), and I show you a memory leak in about 20-30 lines of Java.
I don't buy that. What you call a "leak" is either "unintentional object retention" (which I admit sounds a bit like a cop-out but is really a different problem), or a bug in your JVM. I look forward to seeing your example code.
Solar wrote:
As for the Wiki page "Garbage Collection", I have a serious complaint with this paragraph
So fix it (that's why it's a wiki). It was written by someone who has admittedly never implemented malloc() before. :-[ Based on your description however, it still sounds like it has linear time complexity in the worst case, which is the point I was trying to make. The data point I have to go by is the history of the Windows heap manager, which had to undergo some big changes between NT4 and Win2k because it didn't scale well on multiprocessor systems.
Quote:
I am willing to admit that GC has its uses, but I don't agree to biased... well, "propaganda" for lack of a better word.
I'd suggest finding a better word. What I'm seeing in this thread is a lot of opinion based on "gut feelings" and not much research into how GCs actually work and when to use them, and when
not to (which I have already covered several times).
Quote:
And then there's the issue of C/C++ allowing pointers, and pointer arithmetics. Unless you want to write your kernel in C#, VB, Java or Python, you simply replace the issue of remembering to do proper memory cleanups with the issue of remembering not to do The Bad Thing (tm) with pointers - which is probably rather hard to avoid in kernel space.
Agreed. I think several people on this thread (including me) have already said that GC and "unmanaged" languages do not mix.
beyond infinity wrote:
Just my 2 c: I wouldn't want a gc thread halt my system critical tasks in kernel land just because of some garbage collecting stuff.
This is why it's been said a few times that a
compacting GC in the kernel is a really bad idea. Note that there are non-compacting GCs that don't have to halt anything (e.g. -- concurrent mark-sweep).
Quote:
I wouldn't find it very funny if a gc tiptoed over the borders of virtual memory management and messed up all the objects allocated for vmm stuff.
Just because there is a GC in the kernel doesn't mean everything has to be managed by it. Having the GC manage VMM structures is like implementing your physical memory manager with kmalloc().
Quote:
Further, despite gc sounding quite cool for development it also generates an increasing hankering for lazyness among the not so trained and experienced developers. Omitting a free here and there, ah, the gc will take care of it, I don't mess with it - that sounds most prolly inviting to someone who doesn'
t really want to be busied with programming nitty gritty like freeing allocated objects as soon as they aren't used.
I've heard this argument many times, and I think what overrules it for me are the advantages of GC (again, not necessarily an in-kernel GC, but GC in general). In a nutshell, explicit deallocation introduces the possibility of dangling pointers and double-deletion bugs, which makes having a strictly type-safe language nearly impossible. It's great that developers like us (with our strong work ethic
) are careful enough to do great things with "unsafe" languages like C and C++, but we're a very small minority. The world needs more software than what we alone can write.
IMO it's better if the programming language can help to avoid such bugs related to type-safety.
In terms of laziness, I've thought of a better way to characterize that kind of laziness in a GC language -- being careless about using "new" too much. What bugs me about Java is that it gives you very little choice in the matter. At least C# has structs that can live on the stack or inline (although you allocate them with "new" as well -- a syntax I find baffling coming from a C++ background). Still, I would rather have someone write code that generates too much garbage (which affects performance) rather than code which accidentally deletes an object twice and causes a crash in a completely unrelated part of the code (which affects correctness and is a major pain to debug).