Disabling the garbage collector

Miscellaneous Topics
#1

Hi all!

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.

What do you think?

#2

Crap.

Each non trivial java program allocates memory. preallocating is a waste of memory and can even degrade performance.

Manual memory management really breaks everything java stands for. Why don’t you use just C++?

#3

[quote]I was thinking about a new feature of the VM that would be to completly disable the garbage collector with a command line option
[/quote]
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.

#4

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

  • J
#5

Crap?

[quote]…preallocating is a waste of memory and can even degrade performance
[/quote]
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
[/quote]
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.
[/quote]
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.

#6

[quote]Crap?
[/quote]
Excuse me. Of course not. I wanted to say ‘I don’t like the idea’.

Don’t think so. Most Java game developers? Who?
And they do it to open otherwise closed doors, not for performance. To access joysticks e.g… And of course they feel bad about it.

The more complex a system gets, the more a GC may help to IMPROVE performance. And we want to do the complex ones here, right? Leave the simple once to these poor C++ guys… :slight_smile:

#7

[quote]The more complex a system gets, the more a GC may help to IMPROVE performance
[/quote]
Could you explain further please?

#8

[quote]Could you explain further please?
[/quote]
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.

#9

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 …

#10

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

Cas :slight_smile:

#11

[quote]AnalogKid
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
[/quote]
d) they have to be mutuable (sometimes dangerous)
e) they have to be of a certain type
f) the max. number needed at any certain time must be determinable and decent

I’d use object pools at certain hotspots. Not as a general concept.

#12

Aye. A great example is the player laser beam, which fits all these criteria perfectly. Aliens, on the other hand, don’t.

Cas :slight_smile:

#13

Thank for your replies guys. After all it was just an idea.

#14

[quote]d) they have to be mutuable (sometimes dangerous)
[/quote]
Excuse my ignorance, but could somebody please explain this? (not sure what is meant by a mutuable object)

#15

Excuse my ignorance, but could somebody please
explain this? (not sure what is meant by a mutuable object)

That means that you can change the object; it’s values.

It’s somewhat dangerous because it can lead to strange bugs wich appear rarly (hard to track down) and it can be slower than trashing the object and create a new one.

#16

Ah right, thanks :slight_smile:

Erik