Well *I* like the fact that you can move the word "java" in the sentence "My game runs java out of memory" just about anywhere in the sentence with occasionally a wee bit of punctionation and it makes no difference to the sentence!
java: my game runs out of memory
my java game runs out of memory
my game: java runs out of memory
my game runs java out of memory
my game runs out java of memory [ok this one fails]
my game runs out of java memory
my game runs out of memory - java
kinda like the ploughman homeward wends his weary way.
ok, i guess that didn't help at all. but it amused me.
That's sort of the opposite of "only"; I can't remember the sentence right now, but there are a few for which you can make seven different meanings by placing "only" into a six-word sentence.
When I'm directing or teaching theater, I often use the sentence
I didn't steal grandmother's false teeth.
which, by putting emphasis on successive syllables -- without even adding a word -- you can make sentences with six different meanings.
If a programmer told me he had made this change, here's what I would check.
I would check and make sure that universal variables are maintained--unless all the data necessary for the game is serialized. But there's gotta be some server config data that doesn't change from game-to-game. . . I would think. So I would make sure any unserialized data isn't thrown out with the trash. :) Then I would check the serialized output and ensure that all the data integrity was maintained. I would run at least 5 cycles of serialization with different parameters to ensure nothing odd happens.
Reading up on how this gc funx works, it is both cool and incredibly frightening how this memory management system works. But then you're assuming that the programmers of this serialization code were good about releasing something when it should be released, and that they didn't just leave it on the heap assuming it would be available later. If your code passes those two tests, my belief would be that it would be a good fix.
You're on the wrong track with the universal/serialized variable stuff. There's no state preserved between games, and everything's getting piped through properly -- that's easy to tell. (And I've got kerjillions of successful serialization attempts.)
I'm pretty certain that it's just that the serialization code is kinda crappy in terms of how it handles memory. Unfortunately, it's not something I can muck around with; I need to fix it from the outside.
I'd just set up my installer to install the game with a shortcut that defaults with a "-Xmx 256M" flag. In the EULA, in very small type, I'd tell the customer that they're agreeing to let me muck about with how Java works on their system and include language stating that they agree to hold harmless and forever indemnify me for any damage that this may cause to their systems.
But I'm not a programmer, I'm a lawyer.
That's what I was thinking. Not hard in Windows or Unix, and I don't see a downside.
I think System.gc() is also safe, but not always reliable - it is a *suggestion* that "hey, you could run the garbage collector now if you want," but it doesn't *force* garbage collection. I have been bitten by this.
I'm almost certain ng_nighthawk's concerns are unfounded, unless I'm misreading what he's saying. gc() won't collect memory that still has pointers to it.
We can't have an installer because 90% of our target market will be playing the game on machines where they don't have permission to install anything.
However, we could probably get away with a self-executing batch file or something like that. Any suggestions on places to find patterns to follow?
Ah, but there is no installer.
The primary reason for this strategy is that the default operating environment is a college computer lab where the users don't have permission to install anything -- but they do have permission to save a file to the desktop and run it.
I have an email to the lab's law office asking what kind of disclaimer/license we need for this. Haven't heard anything back yet...
Since you get to cut-and-paste to a mailing list, the least I can do is cut-and-paste my mailing-list response back into LJ ;).
I suppose it's possible your JVM would die with an OutOfMemory without first trying to garbage-collect all that it could, but my guess is that you've got an honest-to-god loop somewhere that's actively pointing to all that memory. If so, GCing won't help
fix your bug.
As for launching by double-clicking, Java really does fulfill the promise of "write once, break everywhere." Do you expect all your users to have the JVM installed already? The right version of it? With all the classes you need?
Here's an article that might help:http://www.excelsior-usa.com/articles/java-to-exe.html
If you don't mind doing machine-specific downloads, you might also try a batch file or launcher.
So far, the answer seems to be that yes, actually, nearly all of our users have a compatible JVM already installed, and those that don't (typically mac and linux users) are sophisticated enough to install it themselves.
But that article is really useful! Thanks!
Suggestions on how to do a simple batch file / launcher? I'm not at all opposed to machine-specific downloads. They're so common that everyone knows how to deal, and it shouldn't be a big deal on our end to generate them...
I haven't really used Windows since, well since it was called DOS, but can't you just put the java command you want in a file called "double-click-on-me.bat" and then put it in a ZIP file along with the JAR file?
I think the launcher approach lets you make it just a single file rather than JAR + batch file, but I've never done that in Windows-land.
Yeah, but there's enough setup steps already that I really want to make it invisible if I possibly can. "Download this file, then unzip it, then double-click this other file" is guaranteed to have more people get lost than "download this file and double-click it", sadly.
The article you linked to had some suggestions about launchers; I'm going to look into those.
I don't really know squat about java.
That said, does your parser get instantiated once and used many times throughout the program? I.e. something like:
myparser = new XMLparserThing();
If so, you might want to delete the parser object in between uses. A lot of parsers are very sloppy about leaving intermediate data structures around to accomodate a number of access methods.
Then again, I may be speaking nonsense. :-)