Chris Forrester wrote:
[...]
> Running that program, I get a noticable lag every half-second.
Always, in such case, run program with -verbose:gc.
[GC 1573K->1569K(2568K), 0.0043237 secs]
[GC 2052K->2037K(2568K), 0.0044562 secs]
[Full GC 2037K->1089K(2568K), 0.1187422 secs]
[GC 1572K->1569K(2568K), 0.0041880 secs]
[GC 2052K->2037K(2568K), 0.0044570 secs]
[Full GC 2037K->1089K(2568K), 0.1191352 secs]
[GC 1572K->1569K(2568K), 0.0041846 secs]
[GC 2052K->2037K(2568K), 0.0047235 secs]
[Full GC 2037K->1089K(2568K), 0.1225102 secs]
[GC 1572K->1569K(2568K), 0.0041930 secs]
[GC 2052K->2037K(2568K), 0.0043799 secs]
[Full GC 2037K->1089K(2568K), 0.1186064 secs]
(I have allowed myself posting it as plain text, not as screenshot of
cmd.exe - I hope everybody will forgive me...)
Anyway, full GC happens every second or even more frequently, stopping
the world for 0.12s, which is very noticeable. Problem seems to lie
inside program - it seems to allocate a LOT of garbage.
Easiest check is to run program with -Xrunhprof:heap=all,depth=10 and
stop after some time. Then look at table and check where is the biggest
difference between life and allocated data (this shows garbage - just
amount of data tells nothing, because it can be static and not a
problem). Here we find offender at first line:
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
1 47.20% 47.20% 1021920 30 14170624 416 7718 [F
also interesting is
13 0.69% 65.82% 15000 250 605280 262 1 [I
and
17 0.57% 68.31% 12240 30 169728 416 7696
javax.media.j3d.QuadArrayRetained
With 13 we are out of luck (stack trace 1 is unknown), but rest shows
clearly what is the problem:
TRACE 7718:
javax.media.j3d.GeometryArrayRetained.createGeometryArrayData(GeometryArrayRetained.java:1422)
javax.media.j3d.IndexedGeometryArrayRetained.cloneNonIndexedGeometry(IndexedGeometryArrayRetained.java:97)
javax.media.j3d.GeometryArrayRetained.updateMirrorGeometry(GeometryArrayRetained.java:9954)
javax.media.j3d.RenderingAttributesStructure.updateObject(RenderingAttributesStructure.java:185)
javax.media.j3d.MasterControl.updateMirrorObjects(MasterControl.java:2565)
javax.media.j3d.MasterControl.runMonitor(MasterControl.java:3230)
javax.media.j3d.MasterControl.doWork(MasterControl.java:2817)
javax.media.j3d.MasterControlThread.run(MasterControlThread.java:28)
TRACE 7696:
javax.media.j3d.IndexedGeometryArrayRetained.cloneNonIndexedGeometry(IndexedGeometryArrayRetained.java:91)
javax.media.j3d.GeometryArrayRetained.updateMirrorGeometry(GeometryArrayRetained.java:9954)
javax.media.j3d.RenderingAttributesStructure.updateObject(RenderingAttributesStructure.java:185)
javax.media.j3d.MasterControl.updateMirrorObjects(MasterControl.java:2565)
javax.media.j3d.MasterControl.runMonitor(MasterControl.java:3230)
javax.media.j3d.MasterControl.doWork(MasterControl.java:2817)
javax.media.j3d.MasterControlThread.run(MasterControlThread.java:28)
Data is not allocated in program, but in java3d. It has to expand
indexed geometry before feeding it to renderer. For some reason, it
seems to create a lot of temporary structures there (probably a design
decision, because one of reasons to use indexed geometry is to save
memory - would be bad if java3d would keep full expanded copy for all
the time).
Solution:
a) Use java3d 1.3, single index for all types of vertex data and hope it
will be accelerated without expanding.
b) Do not use indexed geometry.
I wonder from where [13] garbage comes - it seems to be only few very
big int[] objects... Anyway, I also suspect indices.
Artur
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
