Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Windows process memory going crazy with Xith  (Read 2977 times)
0 Members and 1 Guest are viewing this topic.
Offline Zer Gut Shnitzel

Senior Newbie





« Posted 2006-03-04 05:37:54 »

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
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #1 - Posted 2006-03-06 11:00:41 »

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #2 - Posted 2006-03-06 17:02:36 »

First of all, consider using alternate vecmath library. One that shipped with Xith3D produces too much garbage opbects.
Yuri, seems to be a good idea. Will you do it ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #3 - Posted 2006-03-06 17:47:19 »

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #4 - Posted 2006-03-07 12:52:34 »

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #5 - Posted 2006-03-07 13:14:18 »

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #6 - Posted 2006-03-07 16:13:13 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #7 - Posted 2006-03-11 12:02:53 »

Hi,

Quote
Look at the "License" part.

"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
(i) 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; (c) to a receipient who has accepted the terms of this JDL;
and (d) You provide a copy of this JDL to each such receipient;

Means that source code of vecmath can not be distributed under BSD license

Quote
(ii) 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 (c) where such terms are no less protective of Sun than the terms of this
JDL.

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.

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #8 - Posted 2006-03-11 17:04:12 »

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 ?

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #9 - Posted 2006-03-13 08:17:56 »

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

Yuri Vl. Gushchin
JProof Group
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline William Denniss

JGO Coder


Projects: 2


Fire at will


« Reply #10 - Posted 2006-03-13 13:00:56 »

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.

Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #11 - Posted 2006-03-13 17:21:07 »

No, IMHO users won't notice that and continue "happily" with the original vecmath library..

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #12 - Posted 2006-03-14 16:20:30 »

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)?

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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #13 - Posted 2006-03-14 17:28:03 »

or contribute it to Java3D project (if nobody already have done that - we should check)
How ? You mean commit it to Java3D cvs ? I don't understand.

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Goliat

Junior Devvie





« Reply #14 - Posted 2006-03-18 15:48:03 »

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 ...
1  
2  
3  
4  
5  
6  
       if ( currentKnotIndex < quats.length - 1 )
       {      
         rotationQuat4f.interpolate (
           quats [ currentKnotIndex + 1 ],
           currentInterpolationValue );
       }


altough there are 2 implementations of interpoate() in Quat4f:
1  
2  
3  
    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 :/
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #15 - Posted 2006-03-18 15:52:21 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Offline Yuri Vl. Gushchin

Senior Devvie




Speak Java!


« Reply #16 - Posted 2006-03-23 09:23:11 »

...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

Yuri Vl. Gushchin
JProof Group
Offline Amos Wenger

Senior Devvie




Everything's possible, but not everything's fun...


« Reply #17 - Posted 2006-05-25 21:27:36 »

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

"Once you start working on something, don't be afraid of failure and don't abandon it. People who work sincerely are the happiest"
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

rwatson462 (33 views)
2014-12-15 09:26:44

Mr.CodeIt (23 views)
2014-12-14 19:50:38

BurntPizza (51 views)
2014-12-09 22:41:13

BurntPizza (84 views)
2014-12-08 04:46:31

JscottyBieshaar (45 views)
2014-12-05 12:39:02

SHC (59 views)
2014-12-03 16:27:13

CopyableCougar4 (58 views)
2014-11-29 21:32:03

toopeicgaming1999 (123 views)
2014-11-26 15:22:04

toopeicgaming1999 (114 views)
2014-11-26 15:20:36

toopeicgaming1999 (32 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!