"nogc" option...
Hello,
After 6 years programming and leading Java developper teams...I think major problem remaing in the JVM is...the garbage collector.
It's not a problem of implementation, but just a bad strategy !
We think in our team that we can seriously improve the global performance of our applications, if the VM had a no-gc option.
There's only one person who knows when ressources have to be released...it's the developper.
Is there any other developpers thinking this way ? Is there any plan to include such an option in future VM ?
[569 byte] By [
deneb30a] at [2007-10-3 1:52:19]
It is impossible to allow explicit deallocation of memory while maintaining pointer safety and pointer safety is one of the single most important features of the java language. For that reason it will never happen.
YoGeea at 2007-7-14 18:50:45 >
OK...Pointer safety is another disapointing thing in Java :o)
When you say "bad strategy" do you mean that it would be better not to have
garbage collection as a feature of the language? When you refer to improving
performance, do you mean that doing garbage collection takes time and that
time would be better spent executing the application (i.e., any time > 0 doing
garbage collection is too much).
I mean that a GC can't know when is the good time to release ressource, only the developper knows.
It results in waist of ressources (Object analysis, copy between heap zones, ...).
The GC consumes time and memory ...but offers no gain (in term of development time) because developpers still have to stricly manage memory usage.
Message was edited by:
deneb30
Can you explain more about this nogc option? For exampleif the nogc option is used, is there an object heap that is managed by the VM?
Ok.
The memory allocation/free could be managed by the JVM, but should be commanded by the developper.
For example :
Object myInstance = new Object();
...
myInstance.dispose();
///
Then the object space is marked free in the heap...and further access is forbiden/unpredictable.
How would you manage it with java.lang.String ? It is immutable and it is perfectly ok for any library call to cache it in internal structures.
String str = "My string " + someData;
call3rdPartyLibraryMethod(str);
Can you call str.dispose() ?
Before you mention reference counting and smart pointers, there is an answer for you - it is called C++.
To achieve what you want to achieve, ENTIRE java would have to be redone from scratch - core library, every 3rd party library out there, all patterns you are used to work with, etc. At this point is is really easier to take C++ and port these few libraries you may need from java.
abiesa at 2007-7-14 18:50:45 >
I don't any problem with this example.I allocate the String, I can dispose it when I want.If you call the "thirdpartylibrary" before it will produce the good response...otherwise it's unpredictable.Where's the problem ?
class ThirdPartyLibrary {
String cachedVal;
public void init(String val) {
cachedVal = val;
// cachedVal = new String(val);
}
public void callMeLater() {
System.out.println(cachedVal);
}
}
How do you know if you can dispose a String after calling an init method and before calling callMeLater ? Have I done a copy or I'm just storing the reference ? With current String implementation, even if I'm doing new String(val), I'm still storing reference to the same char buffer, so even in such case you will be never able to dispose the string you have passed.
Example given here is of course trivial - but with many layers (think about any J2EE application) from which you have a source maybe for 20% of them, you will have absolutely no clue who is caching what immutable values at which point.
C++ tries to solve it with copy-on-assignement. How do you want to solve it with your explicit-destructor proposal ?
abiesa at 2007-7-14 18:50:45 >
Ok...I see.I had forgorten the existence of this "heretic" design...It's clearly not compatible with a clean memory management.So sad.Sorry for disturbing...
Hi deneb30,
I assume that you are not deliberately trolling, being on a Java forum and saying "one of the central Java design features sucks".
IMHO your opening comment is similar to saying that C would be great, if only it did not have pointers or machine-efficient int values. Those are central features of C wrt to (say) Ada or BASIC or LISP.
~50% of all programming errors in C/C++ are demonstrably pointer/memory related, so clearly for programmers less capable than yourself it *isn't* possible to handle explicit raw memory allocation and deallocation safely. In general in large projects with multiple modules pointer handling and object lifetime is one of the hardest issues, and indeed is one reason that STL is useful in C++, to mitigate the problem.
I'm a fairly experienced programmer (raw binary machine code upwards) and have been paid I don't know how many $$$ over the years to turn out production-quality systems in C/C++ and I know that one of Java's central attractions is that I *cannot* make that whole slew of mistakes in my Java code that I continue to make in my C/C++ in spite of my best efforts/
Java without GC is not Java. But nothing stops you nulling out your references to help GC along when you want it. I do it in very resource-intensive sections of code.
I just don't think that this discussion is useful.
Rgds
Damon
Message was edited by:
DamonHD
Hi DamonHD,
I'm not trolling...just facing many problems related to memory management.
I used to develop with C and C++ for sevral years (4 to be exact) and then 6 years with Java, and my experience says that Java programs have as many bugs then C/C++ ones.
I just say that GC doesn't help me to offert better software to my clients...it just replaces some problems by others. Not more !
Sorry if I shocked you with my lack of respect to Java perfect design ;o)
