Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (527)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (594)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Disabling the garbage collector  (Read 3529 times)
0 Members and 1 Guest are viewing this topic.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Posted 2003-05-23 13:06:15 »

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?

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-05-23 13:15:45 »

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++?


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline leknor

Junior Devvie




ROCK!!!


« Reply #2 - Posted 2003-05-23 13:59:37 »

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
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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #3 - Posted 2003-05-23 14:13:48 »

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

- J

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #4 - Posted 2003-05-23 15:35:44 »

Crap?

Quote
...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.

Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #5 - Posted 2003-05-23 16:15:53 »

Quote
Crap?


Excuse me. Of course not. I wanted to say 'I don't like the idea'.


Quote

I agree with you but why for example most java game developers have to use JNI?  It is generaly for performance reasons.  


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...  Smiley

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #6 - Posted 2003-05-23 17:02:04 »

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

Offline leknor

Junior Devvie




ROCK!!!


« Reply #7 - Posted 2003-05-23 19:19:08 »

Quote
Could you explain further please?
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.
Offline altair

Senior Newbie





« Reply #8 - Posted 2003-05-23 23:17:56 »

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 ...
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #9 - Posted 2003-05-24 08:11:14 »

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 Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Herkules

Senior Devvie




Friendly fire isn't friendly!


« Reply #10 - Posted 2003-05-24 09:55:44 »

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


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.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline princec

« JGO Spiffy Duke »


Medals: 425
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2003-05-24 10:23:52 »

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

Cas Smiley

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #12 - Posted 2003-05-25 23:31:32 »

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

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #13 - Posted 2003-05-26 05:46:27 »

Quote
d) they have to be mutuable (sometimes dangerous)


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

Offline oNyx

JGO Coder


Medals: 2


pixels! :x


« Reply #14 - Posted 2003-05-26 05:55:50 »

>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.

弾幕 ☆ @mahonnaiseblog
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #15 - Posted 2003-05-26 06:17:50 »

Ah right, thanks  Smiley

Erik

Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

PocketCrafter7 (12 views)
2014-11-28 16:25:35

PocketCrafter7 (7 views)
2014-11-28 16:25:09

PocketCrafter7 (8 views)
2014-11-28 16:24:29

toopeicgaming1999 (75 views)
2014-11-26 15:22:04

toopeicgaming1999 (65 views)
2014-11-26 15:20:36

toopeicgaming1999 (15 views)
2014-11-26 15:20:08

SHC (29 views)
2014-11-25 12:00:59

SHC (27 views)
2014-11-25 11:53:45

Norakomi (32 views)
2014-11-25 11:26:43

Gibbo3771 (28 views)
2014-11-24 19:59:16
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!