“While programs in the Java language are theoretically immune from memory leaks, there are situations in which objects are not garbage collected even though they are no longer part of the program’s logical state. This article shows you how Soft references, like weak references, can help applications prevent object loitering by enlisting the aid of the garbage collector in making cache eviction decisions.”
3 types of references instead of a decent garbage collector, just driving me back to C++.
3 types of references instead of a decent garbage collector…
How could a garbage collector solve the problems described in the article?
How could a garbage collector solve the problems described in the article?
You mean: how can the garbage collector solve bad programming?
You apparently didn’t read article… or you didn’t understand it…
I’ve read it just fine. I just think you can always solve these kind of problems without weak referneces.
And one way or the other, you will have to think about it, so it effectively is bad programming if you don’t (or memory requirements are no problem).
Yep, and u can always write it in assembly to make it super fast 😉
If machine (JVM, GC etc.) can do some mundane tasks in *efficient* way – hey, just do it…
It seems that *you* didn’t understand it.
The problems described in the article are just bad programming, and can’t be solved by a garbage collector.
The real problem are people who think that garbage collection fixes bad programming practices, or that it makes the problem of memory management completely go away.
Nice euphemism. If you don’t call it a memory leak, it’s not a memory leak. RIGHT…
Nice euphemism. If you don’t call it a memory leak, it’s not a memory leak. RIGHT…
How do you make a distinction between a crumpled up piece of paper thrown on the floor and a crumpled up piece of paper still held in someone’s hand? i.e., which is garbage and which is not? That’s the kind of gray area which garbage collectors have to consider.
The semantic stuff introduced by WeakReferences and SoftReferences is a big step forward and allow the programmer to give a hint to the garbage collector about stuff which is not strictly defined as “garbage”.
Which brings me back to: it’s easier to be careful and manage your own memory anyway, C++ style. Really. There are a lot of mechanisms you can protect your object salad from falling apart when you delete something: the Observer pattern (notifications in the ~Something()) — but you only should pay the price for those if you really need to use them.
First – using Weak/Soft references is exception, not norm. Rest is handled fine by GC
Second – current SUN GC implementation is good. The issue is that few years ago wasn’t. The sad thing is that various GC related optimizations aren’t rocket science, they are well know for years and should be implemented in JVM long time ago. Sun still moves 2 steps forward and then 1 step back – escape analysis is implemented in Mustang (Java 1.6, current at beta phase) but stack allocation (the real benefit from escape analysis) will be probably delayed to Delphin (1.7).
Third – I have nothing against manual memory allocation (but plz, C++ is abomination ;-)). That said I see no reason why should I care about this low level task while building high level apps. Garbage collectors are able (and Java GC should be) to handle memory managment as efficient as it would be made manually by developer. Java GC at current state (Mustang) is at ~80% of road IMO.