why object pooling? I'd say NO

[runiter]

The G1 garbage collector is supposed lets you specify soft "real-time" constraints.

Thanks for sharing this link Gili. I like the 4th advantage of G1 which I believe addresses jp.lorandi's concern about irregular pauses during rendering:

Predictability: G1 is expected to be more predictable than CMS. This is largely due to the elimination of fragmentation issues that can negatively affect stop-the-world pause times in CMS. Additionally, G1 has a pause prediction model that, in many situations, allows it to often meet (or rarely exceed) a pause time target.

I wonder if a similar GC specification will be or is implemented for Java ME in cellphones.

[jp.lorandi]

It won't be there for JavaME for a long time as it benefits greatly from hardware threads. CMS is not available on JavaME, ditto.

In any case, given the current amount of combinable options available right now, http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp, without even going into Garbarge-First, creating so complex a suite might be a ton of work. Of course it would be of tremendous benefit to have those numbers, extending beyond Ardor, but I think overall there are other priorities on the project right now.

[runiter]

I think overall there are other priorities on the project right now.

agreed

[cowwoc]

It won't be there for JavaME for a long time as it benefits greatly from hardware threads. CMS is not available on JavaME, ditto.

In any case, given the current amount of combinable options available right now, http://java.sun.com/javase/technologies/hotspot/vmoptions.jsp, without even going into Garbarge-First, creating so complex a suite might be a ton of work. Of course it would be of tremendous benefit to have those numbers, extending beyond Ardor, but I think overall there are other priorities on the project right now.

JP,

The premise behind G1 is that you only have to configure two parameters:

-XX:MaxGCPauseMillis
-XX:GCPauseIntervalMillis

and it'll do the right thing. Is there a simple test we can run on our end to compare performance with and without object pooling?

Thanks,
Gili

[jp.lorandi]

No, there's no simple test. You need to create a test suite with proper warmup (JMeter perhaps?), and different test times (e.g.: 3 hours), and run the test with CMS with/without pooling and G1 with/without pooling. It's bound to take 50 man hours at least.

Also you have to take into account the fact that you're using only the Oracle/Sun official JVM, and not OpenJDK, jrocket, gcj, Excelsior Jet, dravik or whatever it's called on android, J2ME JVMs, etc. For instance, we use Excelsior Jet, so your findings would be meaningless to me (unless you open up the test suite, and I can somehow muster the time to compile in Jet, and leave them tests running).

Then of course, you have to be willing to endure your findings being rejected on form objections, as for this kind of topic, everybody has an opinion. Basically it's fool's gold and as such nobody with enough Java experience on their belts will volunteer (myself included) -- this is why you won't find any kind of comparative test on G1 vs CMS being publicly available, or many Java benchmarks for that. This is why on this thread various people ask for a test suite, without takers.

In any case, good luck with your testing!

[MrCoder]

Right, I think our main reason for adding the "optional" pooling does not come from any simple tests or micro-benchmarks, but the fact that we had lots of GC hickups/problems when building a full blown MMO using jME, at NCsoft (where Josh and I worked together)... Those were all due to the massive creations of Vector3's and the likes. I still believe that forcing people to handle their garbage through methods taking a store variable is good, but the pooling behaviour might be less of a benefit with future garbage collectors. What the deal is for mobile phones etc I don't know...