This part alerted my curiosity: .... "One of the tricks to get Java code running fast is to write it like it was C code. This is a point I continually make here and yet you get people that claim that garbage collection is good and fast. The fact is that it isn't."

So how does one bypass the garbage collector? and controls memory in Java to obtain the same results in terms of performance? (Is there any guidelines, articles) and is this the common practice amoung java game programmers?

This part alerted my curiosity: .... "One of the tricks to get Java code running fast is to write it like it was C code. This is a point I continually make here and yet you get people that claim that garbage collection is good and fast. The fact is that it isn't."

So how does one bypass the garbage collector?

You do it by not creating garbage, but if you are on the Sun server VM 1.5 or later I absolutely dispute Mith's claim that this is necessary. It used to be, but it isnt any longer, at least with the Sun VM.

Last GDC I wrote an entire fake Socket stack for our demo that created plenty of garbage for every packet sent or recieved. Running under an app sending 15 or more sends and 60 or mreo receieves a second we saw NO GC pauses at any time during exection the entire show. My current project, JNWN, is getting 250fps on my laptop with NO special handling or pooling of objects. In fact we are currently seeing performance improvements from packages such as Java3D by removing obejct pooling code we were previously using!

These days trying to fight creating garbage falls into the "premature optimization" category, which is always a bad thing.

Write clear, clean well encapsulated code and don't worry about short-lived objects. So long as you don't make them persist past the eden space they wont cause you any harm.

When you DO have a GC problem, start by profiling like you do with any other problem. Chances are your problem isnt what you think it is.

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!

I can back this up.Previously I did some premature optimizations by pooling objects in my game Cosmic Trip. Later I took that out completely, resulting in lots of added garbage (and I checked this) but not perceived performance loss or GC stuttering whatsoever, even in Java 1.4.Recently I did a change in my emulator JEmu2 to save memory. This change also added more garbage to be created: *every* memory read/write now creates a temporary object and there are *lots* of reads and writes done every frame. Again, absolutely no performance loss, no perceived GC side effects, and the change did save about 130MB in one extreme case.I'm not saying Mithrandir is telling bullocks but I wouldn't take his experience as a guide for anyone to follow. Like Jeff said, write clean code first. It's always easier to refactor and optimize clean code than prematurely optimized code. Chances are that if you prematurely optimize, you optimize something that doesn't need optimizing.

*Last week* we published a game that in early release was unplayable on a 3Ghz 1Gb machine because of the insane amounts of GC. IIRC (Kev will correct me if completely wrong ) ceasing to over-allocate objects (bad code, not ours, 3d party) enabled it to run perfectly on 1Ghz machines with 0.5Gb RAM.

That's a pretty huge difference for GC problems, and you're telling me we wouldn't even have seen them if we'd been using the server VM? Yet, getting people to run the server VM is still hard. For instance, has sun got around to actually distributing it to Windows users yet, or is it still *only* included in the JDK?

AFAICS, the status quo is that GC is still "a major problem" in Sun's JVM not "a fixed issue", and it will remain that way until *the actual JVM that most people are using all the time* fixes it, NOT merely when *a different VM they have to manually enable* fixes it.

NOTE: this is despite the fact that - in general, with java 1.4 - like everyone else, I've had no problems at all. Maybe it's a java 5 problem?

Good Start - The above is actually correct It was an extreme circumstance tho, larges amount of vertex data being generated every frame - not just 3rd part code but at least partly my assumption of how the code would work (given there was no javadoc )

That said, I don't think GC for the general game case is a problem. However, that's not a reason to just go off and write anything because it looks pretty. I've found in the past that quite often the memory use ignorant solution is often not the fastest/most elegant/appropriate anyway.

Of course the rule still applies, you write your code how you want it to be - then profile - if you get problems then work it out. You simply can't predict whats going to happen under the hood anymore, the system just has to many variables for the average mind to determine. Which is exactly what we did with the game mentioned above, code, test - fix.

*Last week* we published a game that in early release was unplayable on a 3Ghz 1Gb machine because of the insane amounts of GC. IIRC (Kev will correct me if completely wrong ) ceasing to over-allocate objects (bad code, not ours, 3d party) enabled it to run perfectly on 1Ghz machines with 0.5Gb RAM.

Two comments...

(1) We're working on it, thats what the two-stage VM is all about

(2) "Insane" amounts of *anything* is likely to cause trouble. Thats why I told the poster "IF" he has a problem the next step is to profile and tune

Quote

That's a pretty huge difference for GC problems, and you're telling me we wouldn't even have seen them if we'd been using the server VM? Y

Likely the imapct woudl have been significantly smaller but, as I say, insane amounst of anything is bad. Thats sorta what "insane" means...

OK so I conclude that it is not the standard approach to programming j2se games,

I have programmed j2me games and also j2se applications but i am used to do game programming in C++, I will code as I would a normal j2se application and then profile it and "optimize", I just wanted to check if I was not falling into a performance trap. Early optimization is usually a bad thing, but being new to the block I thought it would be of good tone to actually ask more experienced people aka Gurus

I use 1.5 for my current game and had a lot of problems with gc (client vm)... the game would stutter every 3 or 4 seconds...

now when using pooling, and almost not creating any garbage it runs as smooth as anything... no gc stutter anymore... :-)

so for me... I definetely needed to use pooling and stuff... and even if it wouldn't stutter without, I can't imagine getting performance improvement for not using pooling (at least for my game)... I just can't see creating new objects all the time being faster than reusing already created objects...(It could be on par with a good vm... but not faster...)

And using pooling doesn't mean writing unclear and sloppy code... (as some people seem to think)... just make sure you plan it good, and that you are very sure about at which points you free objects (letting them enter the pool)... and where you reclaim them...

... and if you plan for it early on... it's very easy to create methods to turn on or off the pooling. Just make sure that you have to call a certain method to get a new object (not using constructors)... then with pooling enabled it will take an object from the pool, when disabled it will create a new object. This wont take much extra time if you do it when starting coding... but optimizing after you've run into trouble with gc might take you alot of time... (so I don't agree to always just code along making the code look pretty and don't worry until profiling... with a bit of planning you could save alot of time...)

I use 1.5 for my current game and had a lot of problems with gc (client vm)... the game would stutter every 3 or 4 seconds...

Did you try to tune the GC before you went to pooling?Some object pooling is already going on 'under the hood' and in my experience this usually works well enough. If it doesn't, playing with the GC tuning parameters can help even more.

But, you do have a point. By doing the pooling yourself, you rid yourself of any dependency to some smartness of a particular VM.I guess much depends on what kind of objects you are creating/pooling; if you have to create/destroy many 'heavy' objects, pooling can make sense.

1. Alien Flux creates almost no garbage whatsoever, at the expense of having a rather complicated pooling system for particles and other objects that tend to get created and destroyed a lot like player lasers. I wrote that, er, 2 or 3 years ago or something.

2. Ultratron has no pooling whatsoever and creates just as many particles and sprites. The code is almost trivially simple to understand compared to the Flux code (you can see that for yourself if you look) and I'll be damned if I can see any difference.

3. If you have a finalizer anywhere you bugger GC good and proper so make sure you're not creating stuff with finalizers. Similarly WeakReferences etc. are far more complicated to handle so avoid using them if you can.

4. As Jeff says, just because you don't have to think about it doesn't mean it's not free: every tiny bit of garbage you produce requires a tiny bit of CPU to clear up later.

5. Optimising GC before you've actually finished writing the game is like eating pudding before you've had your dinner.

3. If you have a finalizer anywhere you bugger GC good and proper so make sure you're not creating stuff with finalizers. Similarly WeakReferences etc. are far more complicated to handle so avoid using them if you can.

Since we were dealing with 3rd party code, I spose there's a chance this could have happened?

hoho... since everyone here seemed so sure I had to go test to turn off pooling again...

and guess what... no stuttering!... I was proved wrong... (at least when I'm the only one playing... it remains to be tested with many players logged in...)

It was a while ago when I implemented pooling... back then I had a lot of stutter... I was running with the default configuration of memory and gc when I started out. Then when I implemented pooling most of the problems went away...

some time later I found the flags to optimize the gc and memory use (still had some stutter but only very occasional back then)... ( -Xmx32m -Xms32m -XX:+UseConcMarkSweepGC -XX:NewSize=1000k -XX:MaxNewSize=1000k is what I use now)..

Of course by then I'd already implemented pooling... and never thought to try without again... so you can happily disregard the things I said before... :-)

WOW... this thread just shows me how immature the java game field is, there are no "de facto" or "de jure" rules, it would be nice to have a white paper or a nice article series about creating "Best Practicies" in the field, like the ones you get from the Effective C++ book series and Game Gems series.

The amount of contradictory or parametrized (as in you have to change certain VM parameters to get the performance) information is overwellming, and confusing.

Do any of you write articles (or white papers), to explain this in a clear (theory and simple examples) way?

Is there any publication (or website) dedicated to java game programming (tricks/gems)?

And many of the people in here are probably the world's most experienced experts in this particular field (not that I'm blowing me own trumpet or owt, but it's true). So ask away! And weigh the answers.

WOW... this thread just shows me how immature the java game field is, there are no "de facto" or "de jure" rules, it would be nice to have a white paper or a nice article series about creating "Best Practicies" in the field, like the ones you get from the Effective C++ book series and Game Gems series.

The amount of contradictory or parametrized (as in you have to change certain VM parameters to get the performance) information is overwellming, and confusing.

How does your confusion make the entire java game field so immature?For example, to get performance the most well known 'best practice' is to write clean code first, then profile, then optimize. Tuning the VM can sometimes be part of the optimization process, comparable to changing optimization parameters in a C++ compiler.Of course there are many shades of gray which might sometimes lead to some contradictory, whichever development environment you use.

That said, of course java is not as mature as C++ as a game development environment, but C++ has been around a lot longer so that isn't really surprising.

erikd: I did not intent to attack, just stating a fact... I read many books and articles, so it is a bit of a surprise (to me) that the most common mistakes and pitfalls for java desktop game programming have not been resolved into a set of best practices (tricks or gems) like in the many c++ publications in the form of book or magazine article.

Also if you look at the general app J2SE field there is already allot of best practices. Game programming is a less mature field of the java panorama, only after jdk1.3 with HotSpot (if I am not mistaken) did it become technological feasible to produce a good quality java game, that was 5 years ago, so I was expecting to see more in the field of best practices and commonly accepted techniques, tricks and gems.

Having had experienced people (you guys) kindly reply to my thread i can see that there is not as much "unwritten/unofficial" rules for Java Desktop Programming as i would expect, or an unofficial/unleashed guide to java desktop game programming.

To All...I am new to the java desktop game field, i do come from a C/C++ background but i am not a purist and i don't want to start any useless discussion about languages (C++ vs Java) it is simply a waste of time both have it's pros and cons, i refuse to get into that kind of discussion.

I am here to learn with you all, most of you are pioneers, i love that feeling of being the first to find out a way to do something or brave into unknown or uncharted territory, i am only beginning so I have much respect and admiration for all of you and kindly thank you for receiving me into your ranks, with time i hope to climb the latter to the top, and earn your respect in return.

I understand that from time to time there will be some hotter discussions, some unkind remarks, some open flame wars, such is the nature of the best... (it always happens in web forums).

I like to read structured information in the form of books and articles (admitting to the static nature, they tend to be more organized and well thought than web forums), but from your replies i can see that this is the best source of information on the subject and that i am in the right place, talking to the right people

I didn't take your post as an attack, I simply didn't understand it as I see that there is quite a lot of knowledge readily available and AFAIC this thread mostly proved a commonly known best practice regarding GC. I just didn't understand why you see this as a sign of immaturity.There are a number of good books for games (I only read Andrew Davison's book but though it was quite good, but I hear there are more good ones), there is Jeff's Performance Tuning book (a bit outdated, but still very useful), there is this site, and there's probably a lot more available too.

But, like I said, compared to C++, of course java is not as mature for gaming. As I see it, this is to be expected, and there's more to it than just C++ vs. java: The fact that VM technology is so rapidly evolving, some 'best practices' are bound to change a lot. For example, object pooling used to be a common good practice to avoid GC stutter. Not so anymore. On the old MS VM, inlining code manually or otherwise uglyfying your code (like using fixed point calculations instead of the now quite fast floats) was needed to squeeze performance out of it. On recent VM's this can even make performance worse. And let's not even start about J2ME, where things are very different.Maybe this confusion is where your feeling of immaturity comes from. If so, you do have a point. This community is probably where you will learn the most because, as Cas said, many experienced people come here and even the Sun folks come here to keep us updated and clear up confusion.

There's very very little available in printed form right now but for three good reasons:

1. It only became feasible to write high performance graphics bindings with the advent of Java 1.4 (not 1.3)

2. Only very recently did LWJGL and JOGL arrive on the scene (LWJGL not long after Java 1.4 was released, JOGL about a year later) and both APIs are still more or less in alpha, meaning that they change in ways that tend to break existing code from time to time. Not a good point to start writing a book from!

3. Nobody's really cared that much until very, very recently, now that Java is both fast and capable.

Hanging around in here you are probably going to be at the cutting edge of Java games development and after a while as qualified to write that book yourself as any other. My best advice is to write a game in Java and find out about it all for yourself

I think we should set up a special topic and put Jeff, Blah^3 and Mithrandir in there along with twelve spurious "facts" about this and that and see how big the fireball gets. I'll moderate it by fanning the flames

If you'd like to start one, you can create one as part of JGF (link below). Iv'e been long wondering how best to present info on such things - FAQ format, article format, what?

Unfortunately I already have to much in my plate, time management is a skill that i still do not master, i work 18h a day (like most people in the industry, sometimes more) there has to be a smarter way to work (like Dilbert strips use to say: work smarter not harder) i for one have not found that path.

In terms of format i like to have article format with some simple examples and if possible benchmarks, something in the lines of Dr. Dobbs articles (theory first (including historical background if possible), then some code listings and sometimes benchmarks showing the difference between implementations).

WOW... this thread just shows me how immature the java game field is, there are no "de facto" or "de jure" rules, it would be nice to have a white paper or a nice article series about creating "Best Practicies" in the field, like the ones you get from the Effective C++ book series and Game Gems series.

The amount of contradictory or parametrized (as in you have to change certain VM parameters to get the performance) information is overwellming, and confusing.

Do any of you write articles (or white papers), to explain this in a clear (theory and simple examples) way?

No.

I can over simplify for you how the GC works, but if you really want to understand it, you need to read at least one master's thesis.(Thats what I did, awhiel ago. It was the thesis of our primary GC guy at Sun. I understood about half of it.)

Fast GC is really a rocket-science subject.

Is there any publication (or website) dedicated to java game programming (tricks/gems)?

As others have said, this forum is probably the best colelctio nof that you will find.

Part of the problem is that various tricks that made sense in the past, have becoem nonsensical or even destructive as VM technology has improved. Even the best book you can fidn is loikely to have somewhat old advice. That beign said, the book by the guys at Full Sail isnt bad as far as it goes. Ther may be a few others around thata re both recent and authoratative enough to be useful.

But the best game programmers seldom have the time to write bnooks or white papers. Its the nature of the business. They are already incredibly over-loaded just writing their games.

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!

WOW... this thread just shows me how immature the java game field is, there are no "de facto" or "de jure" rules, it would be nice to have a white paper or a nice article series about creating "Best Practicies" in the field, like the ones you get from the Effective C++ book series and Game Gems series.

If you havent read Josh Bloch's Effective Java yet, do.

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!

As others have pointed out, the Java game space is still fairly rpaidly evovling.

The other thing to remember is that game programming is not the same as enterprise programming.

In enterprise programming, the problems are all well known and by and alrge old, aand new techniques emerge slowly if at all.

The whole point of game development is to "go where no-one has gone before" and ahdrware and software is constntly evolving.

For this reason I wouldn't use the term "best-practices" for the Game Gems series. "Particulalrly useful approaches to point problems people have used in the past that may or may not apply directly today" would be a much better description.

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!

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