Hello, I've recently started adding substantial quantities of extra geometry to my application, and I'm starting to see horrible garbage collection pauses, typically around *2 seconds* and sometimes more.
(I'm ataching a screen shot to illustrate the complexity of my scene).
I've tried to be careful not to generate garbage, so I investigated using
'-Xrunhprof:heap=sites' to find the culprit. The results seem to point primarily
at Shape3D.intersect(), although there is some evidence that
Locale.pickAllSorted()is also an offender.
I make *extensive* use of these routines each time a frame is rendered (tens of
calls per frame), primarily in order to do collision detection. I use PickRays
and PickSegments on my geometry based picks.
Here's the hprof evidence from an extended run under Win2K:
...
TRACE 15431:
javax.media.j3d.GeometryArrayRetained.intersectRay(GeometryArrayRetained.java:7182)
javax.media.j3d.TriangleStripArrayRetained.intersect(TriangleStripArrayRetained.java:57)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:651)
javax.media.j3d.Shape3D.intersect(Shape3D.java:540)
...
TRACE 15430:
javax.media.j3d.GeometryArrayRetained.intersectRay(GeometryArrayRetained.java:7181)
javax.media.j3d.TriangleStripArrayRetained.intersect(TriangleStripArrayRetained.java:57)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:651)
javax.media.j3d.Shape3D.intersect(Shape3D.java:540)
...
TRACE 15460:
javax.media.j3d.GeometryArrayRetained.intersectSegment(GeometryArrayRetained.java:7426)
javax.media.j3d.TriangleStripArrayRetained.intersect(TriangleStripArrayRetained.java:83)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:634)
javax.media.j3d.Shape3D.intersect(Shape3D.java:579)
...
TRACE 15459:
javax.media.j3d.GeometryArrayRetained.intersectSegment(GeometryArrayRetained.java:7425)
javax.media.j3d.TriangleStripArrayRetained.intersect(TriangleStripArrayRetained.java:83)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:634)
javax.media.j3d.Shape3D.intersect(Shape3D.java:579)
...
SITES BEGIN (ordered by live bytes) Tue Feb 11 21:39:50 2003
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
1 10.11% 10.11% 11393088 237356 796515264 16594068 15431 [D
2 10.11% 20.23% 11393088 237356 796515264 16594068 15430 [D
3 5.75% 25.98% 6474624 15564 6474624 15564 5738
javax.media.j3d.QuadArrayRetained
4 4.15% 30.13% 4680048 97501 1834835136 38225732 15460 [D
5 4.15% 34.29% 4680048 97501 1834835136 38225732 15459 [D
...
Look at the 'Allocated Bytes' column and compare with the 'live bytes' column.
This suggets to me that these routines have generated about *5 Gigabytes* of
garbage during my run. The 'live' data seems to be occupying 30% of my heap, or
about 30MBytes, which is a huge overhead.
So, to my Sun Colleagues,
1) Would you consider this to be a bug ?
2) Is there anything that your could do about this ? I'm wondering if there
might even be some temporary storage that you are allocating that you could
release earlier(i.e. null out), which might give the generational garbage
collector the opportunity to reclaim more efficiently.
I have to say that the rendering and picking performance for my app is extremely
good, but this garbage problem is starting to kill me.
I also suspect from other tests that largish amounts of garbage are being
generated at the following location:
javax.media.j3d.Transform3D.<init>(Transform3D.java:87)
javax.media.j3d.SceneGraphPath.<init>(SceneGraphPath.java:61)
javax.media.j3d.Picking.getSceneGraphPath(Picking.java:362)
javax.media.j3d.Picking.pickAllSorted(Picking.java:88)
javax.media.j3d.Locale.pickAllSorted(Locale.java:599)
rob.kit.KitUtilities.pick(KitUtilities.java:64)
Rob
--
Rob Nugent
Sun Microsystems, Southampton, UK
[EMAIL PROTECTED]
Tel: +44 (0) 1489 585503
Fax: +44 (0) 1489 881363
<<inline: capture.jpg>>
