I'm having Java issues.

[timmermac]

I am not sure if either Java is not working exactly as it should on my system, or if I'm just a complete noob and am doing something completely wrong somewhere.

I am trying to set Java so that it will have both a minimum and a maximum of 1000 megabytes for heap space. I've done this by going into the Java section of my Windows XP control panel, clicking on the Java tab, and then in the runtime parameters for every version of Java that I have, since I'm not sure what version Forge is using, I've entered -Xms1000m -Xmx1000m. My thinking is that when I take look at Task Manager, I should be seeing javaw.exe using 1000000 K of memory, but I've never seen it use more than about 315000 K of memory. How do I make sure that Java is using the memory that it should so that I can run Forge for more than 3 matches in a row without my system completely bogging down?

Edit: I'm looking at VisualVM, and it shows that my heap is still right around 256 MB in size. For some reason, Java is completely ignoring my command to increase the heap size to 1000 MB. I really need to know how to ensure that Java accepts my heap size commands.

Edit2: I'm about ready to throw up my hands in disgust and go back to an earlier version of this game from back before this whole heap space problem started for me. I am simply unable to get Java to change the heap size that Forge is using. No matter what I do to change it, the heap size according to VisualVM is always 266ish million bytes. I've tried to bing search ways to change it and none of them seem to make a damned bit of difference. Or, could someone answer a question: Is it possible to run an already fully compiled beta release through Eclipse, since it seems that it might be easier to actually get heap size changes to stick using that?

Edit3: I've downloaded Eclipse and Subclipse and am running Forge from inside of that. Even with changing eclipse.ini to have -Xms1000m -Xmx1000, running GUI_NewGame results in Forge only getting a heap of 266338304 bytes. I did a text search within the project, and I discovered a few instances of -Xmx1024m, however, I'm not sure that that is ever being reached. I'm thinking that perhaps there needs to be -Xms1000m parameters entered into the code at the appropriate places as well.

[silly freak]

the arguments being present in the source code is not necessary, i don't know how that came about. i don't know how java handles these memory requests exactly, although getting a big RAM requirement when entering the minimum heap size seems logical... you could at least try to use a very small heap size to verify that java runs out of memory faster. if so, your arguments are not the problem

for running from eclipse: have you modified the Gui_NewGame run config to include the VM settings?

[Braids]

hi, i'm Braids. i'm probably the developer most concerned with forge's heap allocation at the moment.

let me start off by saying it's great you have the skills to run this in eclipse and to change all of those settings! these skills can be instrumental in diagnosing the situation! please don't give up.

. . . How do I make sure that Java is using the memory that it should so that I can run Forge for more than 3 matches in a row without my system completely bogging down?

do you actually get an OutOfMemoryError with a stack trace when it is completely bogging down? if not it may be more helpful to run Gui_NewGame in eclipse's debug mode. when it reaches the point where it is bogging you down, like hanging for more than 120 sec, press the pause button in the debugger. teh tooltip for that button actually says Suspend, but it looks like two identical thin vertical rectangles placed side by side, like a pause button on a lot of U.S. electronics. the button is in the Debug tab, i thinkk. i'm restructuring my eclipse installation at the moment, so i can't be as specific as i'd like. anyway, once you hit pause suspend, you can then see where all of forge's threads are at that moment. it's kind of like a live visual stack trace. maybe there's some inefficient loop going on instead of a heap issue.

changing the minimum memory in eclipse.ini's and the Windows Java Control Panel in this respect is only going to make things worse, since i believe eclipse runs in a separate jvm than forge. you're going to run out of physical memory very quickly, and start using virtual memory, which is way slow. if your hard disk is noisy, you'll hear it. if you're running thru eclipse, the only place you need to change these settings is in GUI_NewGame's Run Configuration as silly freak pointed out.

i don't recommend setting the minimum heap allocation but if you must, have you considered looking at Windows Task Manager's other columns? Peak Memory Usage, Page Faults, Virtual Memory Size, and Paged Pool sound like they might be relavant.

Edit: I'm looking at VisualVM, and it shows that my heap is still right around 256 MB in size. For some reason, Java is completely ignoring my command to increase the heap size to 1000 MB. I really need to know how to ensure that Java accepts my heap size commands.

if it were ignoring your commands, you would get OutOfMemoryError exceptions. if you aren't, my theory is that your OS or JVM is maximizing physical memory at 256 MB, and using virtual memory for the rest.

Edit2: . . . Or, could someone answer a question: Is it possible to run an already fully compiled beta release through Eclipse, since it seems that it might be easier to actually get heap size changes to stick using that?

if you svn checkout the revision r# or svn update to the revision r# of the beta, you can then compile and run that specific version's java code and card scripts in eclipse.

i addressed timmermac's Edit 3 above.

Edit 1. in r10519, i have reduced forge's startup time and its heap use by eliminating two temporary lists of OVER NINE THOUSAND items each.
actually, the number is closer to eight thousand. it's still huge.

[timmermac]

Using r10627, I've been able to play 4 consecutive matches without complete bogging down of my system. I'm feeling like I can probably play a few more matches without having to close Forge and reopen it. I have noticed a few minor slowdowns, though. Against Galahad during combat, it took a 30+ seconds after clicking OK on a phase to get to the next phase. That seemed to go away against the next opponent, though, so I think something in that deck makes Forge have to think a bit harder. Also, things stopped moving completely for a couple of minutes against DaVinci, which was my last match, but that too went away. Bear in mind my specs are Pentium 4, 3.06 gigahertz with 1 gigabyte of RAM and an Intel built-in graphics chip and Windows XP SP3. *ahem* anybody know where I can get a couple more gigs of RAM for a 5-year old HP computer cheap?

[Braids]

i'm glad you're able to enjoy forge more!

with that said, i think it's time for me to move on to improving other aspects of forge, such as the AI and forge's capacity for unit testing.

it sounds like its leaking memory. are you editing your deck between matches? with more information, i could add an entry to the developers' issue tracker.

[timmermac]

That depends on whether or not I'm importing a deck to use in questing or not. If I just go with what I get in the starting pool, I'm editing between every match. If I'm importing, then I usually don't do much editing.

[Braids]

That depends on whether or not I'm importing a deck to use in questing or not. If I just go with what I get in the starting pool, I'm editing between every match. If I'm importing, then I usually don't do much editing.

so, would you say the your performance problems are the same whether you use the deck editor or not? and that they get worse the more matches you play?

[timmermac]

Yep. Sometimes I use JVisualVM to see how much heap space Forge is using, and even with the changes you've been making, heap space used goes up steadily. The good news is that the progression has slowed down to the point where I can get at least 6 consecutive matches in before I need to close and restart.

[Braids]

Yep. Sometimes I use JVisualVM to see how much heap space Forge is using, and even with the changes you've been making, heap space used goes up steadily. The good news is that the progression has slowed down to the point where I can get at least 6 consecutive matches in before I need to close and restart.

that sounds about right. the fixes i made reduced the creation of huge temporary lists (usually of all cards). i didn't actually address any memory leaks directly. i'll add an item to the dev issue tracker.