Justin,
I'm seeing a lot of objects allocated in different places inside
Locale.pickAllSorted(). For example observe the "alloc'ed bytes' in the following:
TRACE 15537:
javax.media.j3d.SceneGraphPath.<init>(SceneGraphPath.java:64)
javax.media.j3d.Picking.getSceneGraphPath(Picking.java:362)
javax.media.j3d.Picking.pickAllSorted(Picking.java:88)
javax.media.j3d.Locale.pickAllSorted(Locale.java:599)
TRACE 15558:
javax.media.j3d.Picking.getSceneGraphPath(Picking.java:362)
javax.media.j3d.Picking.pickAllSorted(Picking.java:88)
javax.media.j3d.Locale.pickAllSorted(Locale.java:599)
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
...
18 1.02% 37.31% 1125024 35157 36231840 1132245 15537 javax.vecmath.Point3d
...
22 0.91% 41.20% 1007480 25187 37960280 949007 15558 javax.media.j3d.SceneGraphPath
...
The above are obviously related to the allocation of the SGP that Kelvin alluded
to before (his number (3)). There are a number others. At least some of these I
suspect are due to the 'sorted' nature of this call. I've yet to investigate if
I can eliminate the need for this list to be sorted - I suspect that I can.
Other sites inside Shape3D.intersect() are more worrying to me. E.G.
TRACE 15561:
javax.media.j3d.SceneGraphPath.getTransform(SceneGraphPath.java:201)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:600)
javax.media.j3d.Shape3D.intersect(Shape3D.java:579)
javax.media.j3d.Shape3D.intersect(Shape3D.java:512)
TRACE 15564:
javax.media.j3d.PickSegment.<init>(PickSegment.java:46)
javax.media.j3d.PickSegment.transform(PickSegment.java:93)
javax.media.j3d.Shape3DRetained.intersect(Shape3DRetained.java:618)
javax.media.j3d.Shape3D.intersect(Shape3D.java:579)
percent live alloc'ed stack class
rank self accum bytes objs bytes objs trace name
...
27 0.73% 44.99% 805984 25187 30368224 949007 15561 javax.media.j3d.Transform3D
...
28 0.73% 45.72% 805984 25n187 30368224 949007 15564 javax.vecmath.Point3d
Rob
Justin Couch wrote:
Rob Nugent wrote:
I am still getting substantial garbage collection pauses - around 1.5
seconds.
(3) is indeed an offender, but it is only one of a largish number
(maybe a
dozen) of allocation sites that are generating what I would term
'significant' garbage.
That's interesting, because we don't see that in any of our code and
we're making the same call, just using rays rather than cone. The one
that we most often see garbage being generated from is the view point
code where it is regenerating the vp projection matrix every frame.
There's an int[] somewhere down in the guts of j3d that is allocated and
gc'd every frame that's really annoying. Been a month or so since I last
traced it, so can't remember the class name.
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
--
Rob Nugent
Sun Microsystems, Southampton, UK
[EMAIL PROTECTED]
Tel: +44 (0) 1489 585503
Fax: +44 (0) 1489 881363
===========================================================================
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".
