I was thinking about a new feature of the VM that would be to completly disable the garbage collector with a command line option and then the developer would be responsible to deallocate the objects when they are not used anymore by either/both calling System.gc() or using the added delete expression (like C++) on the object.

If you think about it, for typical 2D games (and perhaps 3D too) you likely never create instances in the rendering loop because you already know the price of creating an instance so why not simply disable the garbage collector at start-up time and manage the deallocation of memory since you should very rarely have to do it?

I already know about the different options/features of garbage collection (http://java.sun.com/docs/hotspot/gc1.4.2/index.html) and that you can tweak the garbage collector to have minimal impact on critical performance apps but even with that there will always have a considerable overhead due to the garbage collector.

I was thinking about a new feature of the VM that would be to completly disable the garbage collector with a command line option

I think we already do this at my place of work. We have some very very short lived java tasks we run from the command line on AIX. IBM told us about an undocumented switch to disable the garabage collector and we disable the JIT so that we get better JVM startup performance. This disadvantage is memory is never deallocated until the JVM exits. That alright for our needs, we just need to make an RMI call or two from the command line.

That doesn't work for programs that run for more than a few seconds. If you required the programmer to manually free memory then it wouldn't be Java, you would be programming some other language.

...preallocating is a waste of memory and can even degrade performance

I don't talk about allocating unecessarly. And could you explain why for example EJB containers use pools of objects for bean instances? I think your argument defeats object cache concepts. Maybe you say that because hot spot would not have enough space to perform some optimizations?

Quote

Manual memory management really breaks everything java stands for

I agree with you but why for example most java game developers have to use JNI? It is generaly for performance reasons. So according to Java phylosophy, JNI is not acceptable because it breaks portability. Even worst, you have to bypass Java at some point by using another language! But developers use it because they have a good reason to do so.

Quote

if you don't allocate memory, you have switched off the GC anyway. It won't run.

Wrong, the garbage collector will continue to monitor objects in each generation of objects by checking the space allocated for each of those generations in the case they fill up the space (collections occur when there is no more space). And there are other optimization checks done by the garbage collector about the space of generations.

The thoery behind this is that the memory manager can do things like re-locate objects in memory to reduce fragmentation. It could reorder objects so that objects that are frequently accessed together are next to each other in RAM such that a they would be on the cpu cache togeher.

There is also the argument that not having to think about when you need to free memory frees your mind to think about more complex solutions that may perform better.

I think in general there are a lot of assumptions behind claims that a GC will be faster, but I'm confident it's been shown to not have that much overhead and definate increase in programmer productivity.

Disabling the GC is a very bad idea: if you do not create objects anyway, the gain would be small. The question is : are you sure you are not calling APIs that DO create objects. In this case, the GC is your insurance against ever increasing memory ...

AnalogKid - garbage collection is in fact faster than using explicit delete. Really. And it honestly doesn't hurt to create objects, even in the rendering loop. Just don't create lots of them in the wrong place - which means looking at what you're doing and where.

Btw - preallocating objects is not universally horrible; but the only time you should do it is if they are a) expensive to construct and b) deliberately limited in numbers and c) rapidly allocated and deallocated inside the rendering loop

AnalogKidpreallocating objects is not universally horrible; but the only time you should do it is if they are a) expensive to construct and b) deliberately limited in numbers and c) rapidly allocated and deallocated inside the rendering loop

d) they have to be mutuable (sometimes dangerous)e) they have to be of a certain typef) the max. number needed at any certain time must be determinable and decent

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org