Windows process memory going crazy with Xith

Engines, Libraries and Tools Xith3D Forums
#1

Hello,

I am having some serious problems with Xith’s memory usage on windows. I have a huge scenegraph but geometries and textures are shared (hopefully). By watching the heap usage I couldn’t see any problems but the process memory usage in windows task manager shows double the size of my current heap. For example on a 750Mb/900Mb of heap space, the process size is 1.8Gb!!! Funny thing is when I remove all the objects form the heap including all the textures and geometries my process size stays at around 1.7Gb. If I start reloading and re creating objects the process size goes up again, not far though as VM crashes as soon as it gets close to 2Gb. Could this be a memory leak outsied of JVM caused by some native functionality of JOGL, buffers, driver, etc.?

My scene graph has more than 10000 nodes and total physical size of textures and geometry is below 100Mb. The funny thing is that I always have enogh heap space as it never goes above 750 and JVM can use up to 900 but my JVM crashes as the process size is huge.

I am running it on ATI X600 with latest drivers, Java1.5 latest update, latest Xith and JOGL

#2

First of all, consider using alternate vecmath library. One that shipped with Xith3D produces too much garbage opbects.

Another point is to determine if memory eaten by Java VM or native part.

For a simple test, try to put explicit GC call in your rendering loop (performance will drop but you will see if this is a garbage problem or native code memory leak).

Yuri

#3

Yuri, seems to be a good idea. Will you do it ?

#4

Hi,

I anyway use that version of vecmath for a long time (nearly from very beginning of Xith3D). It is released in source form under BSD-like license (even less restricted), but the problem is that it uses javax.vecmath namespace, and does not implement some minor features of original one, so, as I think, this is a violation of Sun license for javax.vecmath APIs.

For example, serialized representations of classes in this lib are incompatible with ones from Sun - actually, nearly nobody cares about this, but formally it is incompatible.

As one of Project Owners I have to fulfil all the legal requirements of Sun Open Source policy, so I prefer to stay on the safe side.

Yuri

#5

Oh, I see, ah bloody legal issues…

Could we just rename all javax.vecmath packages (of the lib you’re talking about) to something else and use them in Xith ?

#6

I think we should review license for implementors of javax.vecmath specs again. Could be something has changed…

This is a first step. Another point is that a lot of code for camera manipulation etc. is directly usable with Xith3D if we use same vecmath API. I see this as a big advantage.

Yuri

#7

https://vecmath.dev.java.net/
Look at the “License” part.
What are the “TCK tests” ?

#8

Hi,

[quote]Look at the “License” part.
[/quote]
“The JDL allows commercial use of vecmath with or without modification, as long as compatibility with the entire API Specification is maintained.”

This is what I meant. I am not sure if Kenji Hiranabe vecmath will pass ALL TCK tests (say, serialization).

TCK is “Technology Compatibility Kit”, set of tests to run against API implementation to ensure it is compatible. In some cases it is trivial ckecking of all method signatures defined in API, in some cases - much more deeper testing… say, I did not check the TCK for vecmath, so I can not say if that lib will pass it.

Another point that somebody (me?) has to SIGN the JDL for vecmath.

quote Source Code. You can only distribute source code for the RI and Modifications under all of the following conditions: (a) You make such
distribution under the terms of this JDL; (b) without offering or imposing any different terms; © to a receipient who has accepted the terms of this JDL;
and (d) You provide a copy of this JDL to each such receipient;
[/quote]
Means that source code of vecmath can not be distributed under BSD license

quote Binary Code. You can distribute binary code for the RI and Modifications but only under license terms which (a) have been accepted by the
receipient; (b) are consistent, and not conflicting, with the terms of the JDL; and © where such terms are no less protective of Sun than the terms of this
JDL.
[/quote]
Means "you have to consult our lawers in order to ensure that your binary code license is “consistent, and not conflicting, with the terms of the JDL”, and terms of it “are no less protective of Sun than the terms of this JDL”, and better you have to get written confirmation from us.

Another consequent that “You have to enforce all who download your program to accept terms of your binary license”.

It is only possible to get TCK after signing this agreement (maybe I really shall do that… still thinking).

[quote]If Sun policy (as communicated to You by Sun) also requires verification of compatibility for Your Compatible Implementation then You
shall, prior to the FCS of the Compatible Implementation, submit verification of compatibility to Sun or to an independent test facility designated by Sun. If
such verification is by an independent test facility, then the reasonable costs of such activity (including any applicable fees) shall be at Your expense.
[/quote]
Means that before publishing the lib, Sun MAY require you (or me - this is more realistic - if I wish to publish that lib) to pass certification at some software certification lab at our expence (which - you can be sure - can be not really cheap, because of “reasonable” means different for different people)…

I will treat this as “a kind of pushing (well, not so strong) commercial companies (like mine) to contribute to Sun-supported projects rather than publishing their own implementations of public Java APIs”. This is not so bad in general if we think from strategy viewpoint, but there are different reasons to do or not to do something.

Yuri

#9

Well, that seems pretty complicated to apply to Sun’s criterions.

It may be simpler to just rename all the packages of the “alternative vecmath” lib and then rename imports in Xith… In that case, we aren’t anymore under JDL license, right ?

#10

Hi,

Well, yes, but I think we loose too much of compatibility with A LOT of existing code (say, for skeletal animation, particle systems etc.) which is not so Xith or J3D specific.

I was considering this time ago, but still not sure if it is a good way.

Yuri

#11

Maybe the easiest approach (and to keep everyone happy) is to simply advertise the existance of an alternate vecmath library a bit more (i.e. on the download page)?

Will.

#12

No, IMHO users won’t notice that and continue “happily” with the original vecmath library…

#13

Hi,

[quote]Maybe the easiest approach (and to keep everyone happy) is to simply advertise the existance of an alternate vecmath library a bit more (i.e. on the download page)?
[/quote]
I don’t think so… Even if we point somebody where to get that lib, we will become involved in breach of the license. Well, maybe I am too paranoid, but especially after several cases we had with our SMS Games projects last two years I prefer to say on the safe side.

I think that the best approach is to either push that lib through all this process, or contribute it to Java3D project (if nobody already have done that - we should check). I anyway have signed contribution agreement with Sun, so normally it’s no problems.

Yuri

#14

How ? You mean commit it to Java3D cvs ? I don’t understand.

#15

i just tried to compile xith with the vecmath version proposed above … but it failes due to the fact that com.xith3d.screengraph.GeomContainer uses TexCoord4f which isn’t included in this vecmath version. altough implementing TexCoord4f is a matter of some seconds ( copy TexCoord3f, change every 3 in a 4 and give the constructor a 4th parameter ) it prevents the vecmath library to be used with a clean xith build …
any ideas?

[edit] with the quickfix texcoord4f the xith core compiles fine … but in the toolkit in org.xith3d.behaviors.impl.RotationPathInterpolator the method Quat4f.interpolate() is used which is ambigous according to my compiler …

       if ( currentKnotIndex < quats.length - 1 )
       {       
         rotationQuat4f.interpolate (
           quats [ currentKnotIndex + 1 ],
           currentInterpolationValue );
       }

altough there are 2 implementations of interpoate() in Quat4f:

    public final void interpolate(Quat4f q1, double alpha) 
and
    public final void interpolate(Quat4f q1, Quat4f q2, double alpha)

i don’t see any reason why this should be ambigous :confused:

#16

What are the risks if we add TexCoord4f to the alternate vecmath lib, and include it by default with Xith ?

#17

…I have to mention that I use modified version of Vecmath… and all the missing classes you mentioned are included there.

Yuri

P.S. Magic Spark - Check your PIM

#18

Yuri, check your PM. Maybe we can have alternate vecmath for 0.8