Another garbage collection question

[Ouabaine]

Hello,

Yes, another question about garbage collection.
For my game, I am trying to minimise GC as much as possible, as it induces a
pause in the animation. I know I can use command line arguments to control
the GC, but this game is to be launched by a double click.

-> Is there a way to set the GC behaviour from within the application,
instead of the command line?
-> When I declare an "int", a "short", a "double" in a method, is the space
taken on the heap, or is there a pile for this kind of data? (and what about
"String", is it on the heap or on the pile is it exists)

Thanks for your wise input.

Francois

 

[KevinHanna]

Hello,

Yes, another question about garbage collection.
For my game, I am trying to minimise GC as much as possible, as it induces a
pause in the animation. I know I can use command line arguments to control
the GC, but this game is to be launched by a double click.

Put the command line arguments in the "shortcut" or batch file.

-> Is there a way to set the GC behaviour from within the application,
instead of the command line?

No, you can't control Java's garbage collection. You can only adjust
the heap and stack sizes to effect how often Java runs GC, the
ultimate decision is always left to the JVM. If garbage collection is
noticeably effecting the performance (and I'd be surprised if it is).
Then you'd be better served to make sure you're instantiating as few
objects as possible. Google the singleton design pattern.

-> When I declare an "int", a "short", a "double" in a method, is the space
taken on the heap, or is there a pile for this kind of data? (and what about
"String", is it on the heap or on the pile is it exists)

Primitives (int, short, double, long) are stored in the stack.
Objects (String, Integer, et cetera) are stored on the heap.

 

[Lew]

If garbage collection is
noticeably effecting the performance (and I'd be surprised if it is).
Then you'd be better served to make sure you're instantiating as few
objects as possible. Google the singleton design pattern.

Be careful making that a rule of thumb. Java's GC is optimized for many
short-lived objects. GC from the young generation takes no time for dead
objects. Allocation costs are also quite low, amounting to little more than
bumping the heap pointer. So you're really better served in most scenarios by
creating and discarding objects very quickly.

On the flip side, be careful making /that/ a rule of thumb. Profiling and
-verbose:gc will tell you how you're doing and suggest strategies.

Primitives (int, short, double, long) are stored in the stack.
Objects (String, Integer, et cetera) are stored on the heap.

It's hard to conclude that generally. Under certain circumstances objects can
live on the stack, too.

 

[Donkey Hot]

No, you can't control Java's garbage collection. You can only adjust
the heap and stack sizes to effect how often Java runs GC, the
ultimate decision is always left to the JVM. If garbage collection is
noticeably effecting the performance (and I'd be surprised if it is).
Then you'd be better served to make sure you're instantiating as few
objects as possible. Google the singleton design pattern.

You indeed can start the garbage collection whenever you want, it's just an
API call on Runtime or such (I can't remember). You can start gc when your
app is idle and hope it helps.

 

[Arne Vajhøj]

You indeed can start the garbage collection whenever you want, it's just an
API call on Runtime or such (I can't remember). You can start gc when your
app is idle and hope it helps.

No.

If you read the docs for the System/Runtime gc call you will see
"Calling this method suggests that the Java virtual machine ..." - the
keyword being "suggest".

It is very unlikely that calling gc explicit will improve
performance - it will likely make performance worse.

Arne

 

[Arne Vajhøj]

Then you'd be better served to make sure you're instantiating as few
objects as possible. Google the singleton design pattern.

I think object pooling pattern is much more appropriate than
singleton pattern for this purpose.

But the experts say that today allocation and garbage allocation
are so efficient in Java that object pooling reduces performance
(object pooling for memory reuse - not necessarily for other
resources).

Arne

 

[Daniel Pitts]

Hello,

Yes, another question about garbage collection.
For my game, I am trying to minimise GC as much as possible, as it induces a
pause in the animation. I know I can use command line arguments to control
the GC, but this game is to be launched by a double click.

-> Is there a way to set the GC behaviour from within the application,
instead of the command line?
-> When I declare an "int", a "short", a "double" in a method, is the space
taken on the heap, or is there a pile for this kind of data? (and what about
"String", is it on the heap or on the pile is it exists)

Thanks for your wise input.

Francois

I saw a blog post about this recently: Lots of good information.

<http://chaoticjava.com/posts/gc-tips-and-memory-leaks/>

 

[Roedy Green]

-> When I declare an "int", a "short", a "double" in a method, is the space
taken on the heap, or is there a pile for this kind of data? (and what about
"String", is it on the heap or on the pile is it exists)

local variables go on the stack. The space is reclaimed when the
method terminates.

Instance variables are allocated inside an object. Objects are
normally allocated in the heap, though Jet sometimes moves them to the
stack for speed.

Static variables are allocated inside the class object. It is
allocated on the heap when the class is first used.

 

[Lew]

No.

If you read the docs for the System/Runtime gc call you will see
"Calling this method suggests that the Java virtual machine ..." - the
keyword being "suggest".

It is very unlikely that calling gc explicit will improve
performance - it will likely make performance worse.

If memory is tight when you call System.gc(), it's very likely the VM has just
invoked GC or was just about to, making it superfluous. If memory isn't
tight, either the VM will ignore your request, making it superfluous, or will
honor it with a full GC, not a young-generation collection, thus causing the
very overhead you seek to avoid.

 

[Lew]

Static variables are allocated inside the class object. It is
allocated on the heap when the class is first used.

This last point is the key to a number of idioms in Java that rely on static
members not being initialized until the class is first used, and on them being
initialized before anything else happens with its instances.