Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
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  
  Expanding Heap  (Read 1620 times)
0 Members and 1 Guest are viewing this topic.
Offline drewlane

Senior Newbie




I am the Walrus!


« Posted 2003-12-18 13:11:38 »

I wrote a little bowling game in Java a while back.

It was one of my first games and was a bit of a learning experience.

Anyway, I got my hands on a Java Profiler the other day and I ran this little game through it.

I noticed that the memory heap keeps getting a little bigger as the game progresses.  It started out using around 4MB then climbed to 6MB and eventually started to slow down at around 9MB after 30 mintues or so.  

However, the heap still seems to be growing slowly as the game continues to run.  Garbage Collection seems to be releasing some memory, but not as much as I expected.

Is there anything in particular that I should look for in my code that would explain why more memory is not being released?

Thanks,

Drew

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #1 - Posted 2003-12-18 15:06:20 »

Collections that still hold objects that you aren't going to use anymore.  Maps are easy to fill with stuff you won't access again.

Try a profiler:
http://www.manageability.org/blog/stuff/open-source-profilers-for-java

Offline genepi

Senior Newbie




azerty


« Reply #2 - Posted 2003-12-18 17:55:58 »

Hi Drew,

If your application is running on a PC, you can try the profiler in the Sun JVM. Try
1  
java -Xrunhprofs:help
for help.
There is an option to display all objects still in memory when the application ends (
1  
java -Xrunhprof:heap YourClass
and look at the content of the java.hprof.txt file for results). Well, graphical memory analyzers (like the Eclipse profile plugin) give you more than that, but this one is available almost everywhere...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2003-12-18 18:37:03 »

There is also a command line flag in the sun VM to set the maximum heap.  (-Xmx=  I think but I forget.  Use java -h and java -X to get a list of most of the commandline flags.)

Try setting your max heap and see if you eventually throw an out of memory error. if so, you are not freeing objects.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline drewlane

Senior Newbie




I am the Walrus!


« Reply #4 - Posted 2003-12-19 01:31:49 »

I didn't have much luck dumping the heap with -Xrunhprof - kept getting an error.

However, I did use -Xmx4m as a test and let the program run for at least 30 minutes and it worked fine.

Yet, I'm still not sure why the heap keeps growing when no maximum is set even though I can get away with only 4MB.

Is this just how the VM normally behaves?

Also, how does one determine what the optimum min and max heap size is for a program?

Drew
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #5 - Posted 2003-12-19 05:46:19 »

I think it is absolutely possible and legal that the heap will grow to its limit (common 64MB). I also feel its not legal to make assumptions on how the GC works, when it will run and what it will do. Maybe it free some objects and lets others untouched until it is forced to care for them due to memory restrictions.

If you don't get an OutOfMemoryException with a tight heap limit, your code is fine.

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

JGO Kernel


Medals: 163
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #6 - Posted 2003-12-19 07:30:37 »

So it is ok to make the assumption that should allocation be attempted and no memory is left then the garbage collector will attempt to run and free some memory before the OutOfMemoryException is thrown?

Kev

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #7 - Posted 2003-12-19 12:54:13 »

Yes, absolutely.  The GC must try a full collection before throwing OutOfMemory.

Offline kevglass

JGO Kernel


Medals: 163
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #8 - Posted 2003-12-19 13:01:04 »

Cool, I'd always assumed so, but never seen it written down anywhere Wink

Kev

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #9 - Posted 2003-12-19 13:11:32 »

Actually I think I worded that too strongly..  "must" may not be correct, "will" is correct for current Sun VMs.  As far as I know it might be "allowable" to never collect garbage at all.

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

JGO Coder




Got any cats?


« Reply #10 - Posted 2003-12-19 15:29:31 »

So lesee.. in order

(1) Yes, absolutely.  The VM is trying to maximize the speed at which your program runs.  If it can avoid GCs by growing memory then it will do so within the limits that you've set as acceptable with the command-line flags.

(2) Yes.  The VM is required to make "all good faith efforts", as they say in legal terms, to collect memory before it dies with an "out of memory" error.  As pointed out this doesn't mean that it will collect all, or anything, but it means it will TRY to collect all it can.  (That caveat is because it is actually possible and legal to write a VM which never collects.  IBM did this on some huge hardware with massive address spaces and massive disks where they just swapped data out and threw away address space  until the end of the VM run and then cleaned up the disc and address space afterward.)

(3) Finding the right heap space for you app is an art.  It starts by  a static analysis of what you think your app is likely to use and continues with testing and measuring performance with various sized heaps.  One thing to ALWAYS avoid on Win32 though is a heap so large it causes your app to swap as swapping performance is *terrible* on Wintel boxes.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
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.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (26 views)
2014-09-07 01:11:22

Longarmx (26 views)
2014-09-07 01:10:19

mitcheeb (34 views)
2014-09-04 23:08:59
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

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!