Reducing GC overhead - 2nd edition

Engines, Libraries and Tools Xith3D Forums
#1

Here’s an interesting report made with YourKit profiler : http://www.xith.org/profiling/GC-Q3-Report.html
It shows the most garbage-producing methods. Some like AbstractArray.iterator() are unavoidable but these are just signs of other problems : too much array creation or somewhat.

Some other methods that worry me are the getScale() and invert() methods of Matrix4f : sooo much garbage ? How is it just possible.

BSPClusterManager.setVisibility(Vector3f) could surely be improved.

I’ll now look into sourcecode and profile CPU times.

Note : If you want an open-source YourKit license, just mail me.

#2

Well, I guess most of them are. I’ve never thought into it and realized, that each loop over a List is a creation of an Iterator, which needs to be garbage collected. We could just loop over a List by a regular for (i = 0; i < list.size(); i++) loop. This can also be done very efficiently, and doesn’t produce any garbage.

Strange ???. No idea.

Yes, for sure.

Marvin

#3

Matrix4f problems can be solved, has specified here http://www.java-gaming.org/forums/index.php?topic=11811.0

I’ve done it for my game, and reduced GC to nearly nothing

Lilian :slight_smile:

#4

Does anyone know, where to find this library? I’ll continue to search for it, but so far with no success.

Marvin

#5

http://www.objectclub.jp/download/vecmath_e

Regarding the Licence: there is an overview on the vecmath page. It seems that an implementation must be able to pass suns test suite to be allowed to be redistributed. If I understand correctly, the implementation above complies to the Java3D 1.2 specification and should therefor fullfill this requirement.

#6

So would anyone object using (or first trying) this lib?

#7

Please try it. Since it is an inplace replacement, we could support both alternatives.

#8

I included the alternative vecmath implementation (vecmath-kh.jar) into xith, but the GC is still bad. Amos please remeasure GC. Hopefully the vecmath GC and iterator GC should have dropped to a minimum.

Marvin

#9

Which vecmath lib do the JMonkey guys use?

#10

We wrote our own math lib from the ground up.

#11

Attached is a modified BSPClusterManager that does not create garbage during updates. Rename it to .java, of course.

Also, after profiling your code I’ve discovered that most of your garbage is being created by the recreating of the ShapeAtom in your Shape3D objects everytime it is readded to the scenegraph (as you move around the map and the portal view system does it’s work.) Simply commenting out line 299 in Shape3D where it sets the atom to null in the method setLive(boolean) gets rid of almost all of the extra object creation, makes things very stable and gives you a nice little speed boost (a few frames on average). I’m not saying that’s the solution, but it might give you an idea of how the BSP portal management might need to change.

Hope that is useful!

#12

I already converted (before you mentioned it, Qudus) some enhanced-for loops (Shape3D shape : shapes) to classic loops (int i = 0; i< shapes.size(); i++) which gave me a HUUUUge performance boost ;D ;D ;D ;D From 16.88FPS avg. I have gone up to 16.95FPS Yeah !! great.

Now I’ve commented the line renanse suggested in Shape3D and I’ll see with the different additional improvements how fast is it, and report it to you, of course. :smiley:

#13

Yeah, I already found your code comment about that ;).

Well, I’m not really sure if just commenting out this line is correct. I’ll investigate it. But it will certainly do the trick for this test ;).

Marvin

#14

In fact, we should provide a softcache with RenderAtoms… when the memory usage is > 60-70% the older atoms are trashed. I t hink it would be nice this way.

#15

Well, the atoms will never be “old”. They can always be recycled.

#16

Why ? They do contain shape-specific info so if the shape is removed from the scenegraph or deleted the atom is of no use, if the shape is not re-added later… ?

#17

That’s true. And this is exactly the cause, why I said:

But for scenegraph persistent shapes the atom will never be “old”.

Marvin

#18

Yeah, so we should provide a way to tell that nodes are persistent (thus, their atom should not be deleted). maybe the ones which are static ? (display lists) :smiley: wouldn’t that be nice ?

#19

No. When you remove a Node from the scenegraph the only reference to the Atom is in the Shape itself. So unless you waste the pointer to the shape the Atom is held by the shape and can be reused. When you decide to never reuse the shape and waste the last pointer to it, the atom is wasted, too.

Correct me if I’m wrong, but I think this is possibly the most efficient and convenient way to handle atom wasting, isn’t it.

Marvin

#20

oh, yeah, sure.