Menu
▾
▴
gl4java-usergroup
|
From: <pet...@ba...> - 2002-01-09 09:06:33
|
Are there not two simple solutions to this problem: - You could maintain a pointer to the array yourself. Then the stuff wouldn't get GC'd in the first place. - You could stick your call to gluTessVertex in a display list. Then the garbage collector can let itself loose on the array as much as it likes, cos the data will be (effectively) server-side by then. Or am I missing something here? Pete > -----Original Message----- > From: gl4...@li... > [mailto:gl4...@li...] > Sent: Tuesday, January 08, 2002 8:10 PM > To: gl4...@li... > Cc: gl4...@li... > Subject: gl4java-usergroup digest, Vol 1 #323 - 4 msgs > > > *** WARNING *** > > This mail has originated outside your organization, > either from an external partner or the Global Internet. > Keep this in mind if you answer this message. > > > Send gl4java-usergroup mailing list submissions to > gl4...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > or, via email, send a message with subject or body 'help' to > gl4...@li... > > You can reach the person managing the list at > gl4...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gl4java-usergroup digest..." > > > Today's Topics: > > 1. GC Bug (Pepijn Van Eeckhoudt) > 2. Re: GC Bug (Kenneth B. Russell) > 3. Re: GC Bug (Pepijn Van Eeckhoudt) > 4. Re: GC Bug (Sven Goethel) > > --__--__-- > > Message: 1 > Date: Tue, 08 Jan 2002 16:33:33 +0100 > From: Pepijn Van Eeckhoudt <pep...@lu...> > To: gluser <gl4...@li...> > Subject: [gl4java-usergroup] GC Bug > > While using the GLU tesselator with 700+ points, I encountered very > peculiar behavior. Above a certain amount of points, the end > result of > the tesselation would be completely messed up. After reading the > comments in the Nvidia/DirectBuffer demo about the GC bug, I > took a look > at the native code that handles a gluTessVertex call and > found that no > copy is made of the data that is passed to this function. The OpenGL > manual states that a call to gluTessVertex only keeps a > pointer to the > data array and does not make a copy itself. I assume that what's > happening in my program is that the garbage collector is > moving around > (and probably even freeing) some of the coordinate arrays, > because they > are neither pinned or copied. Is this assumption correct? If it is > correct will this be fixed any time soon? I know that the > problem can be > resolved by using direct buffers, but i would like to have pre 1.4 > compatibility. > > Pepijn Van Eeckhoudt > > > > --__--__-- > > Message: 2 > Date: Tue, 8 Jan 2002 11:50:36 -0500 (EST) > To: Pepijn Van Eeckhoudt <pep...@lu...> > CC: gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > From: "Kenneth B. Russell" <kbr...@al...> > Reply-to: kbr...@al... > > > > While using the GLU tesselator with 700+ points, I encountered very > > peculiar behavior. Above a certain amount of points, the > end result of > > the tesselation would be completely messed up. After reading the > > comments in the Nvidia/DirectBuffer demo about the GC bug, > I took a look > > at the native code that handles a gluTessVertex call and > found that no > > copy is made of the data that is passed to this function. > The OpenGL > > manual states that a call to gluTessVertex only keeps a > pointer to the > > data array and does not make a copy itself. I assume that what's > > happening in my program is that the garbage collector is > moving around > > (and probably even freeing) some of the coordinate arrays, > because they > > are neither pinned or copied. Is this assumption correct? > > It's hard to tell what the GLU tesselator is doing under the hood > from looking at its man pages. If it is holding a pointer to the > passed GLdouble* then you could be correct. An easier way to > determine whether this is the problem is to run with -XX:+PrintGC > (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC > messages at the times when the vetices are corrupted then this is > the problem. Otherwise it could be a bug in your application or > possibly in GL4Java. > > > If it is correct will this be fixed any time soon? I know that > > the problem can be resolved by using direct buffers, but i > > would like to have pre 1.4 compatibility. > > There is no good solution for this kind of problem on earlier > JDKs. Alternatives include performing a data copy via JNI (which > requires an associated free somewhere, which is sometimes hard to > figure out when to do, or having a static data buffer, which > requires synchronization) or performing pinning, which is > complicated or impossible depending on the GC algorithm. > > > --__--__-- > > Message: 3 > Date: Tue, 08 Jan 2002 18:02:15 +0100 > From: Pepijn Van Eeckhoudt <pep...@lu...> > CC: gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > To: gl4...@li... > > In the red book (1.2 third edition) on page 482 second > paragraph, it is > stated that only a pointer is kept inside the tesselator :). The > tesselator kicks in when you call glTessEndPolygon. My > suggestion would > be to copy the data that is passed in glTessVertex calls, and > to free it > after glTessEndPolygon has returned. I modified my program so it uses > direct buffers and this works fine. If I keep the exact same > code, but > pass a double[] it's messed up again, so the problem isn't in > my program. > > Pepijn Van Eeckhoudt > > Kenneth B. Russell wrote: > > >>While using the GLU tesselator with 700+ points, I encountered very > >>peculiar behavior. Above a certain amount of points, the > end result of > >>the tesselation would be completely messed up. After reading the > >>comments in the Nvidia/DirectBuffer demo about the GC bug, > I took a look > >>at the native code that handles a gluTessVertex call and > found that no > >>copy is made of the data that is passed to this function. > The OpenGL > >>manual states that a call to gluTessVertex only keeps a > pointer to the > >>data array and does not make a copy itself. I assume that what's > >>happening in my program is that the garbage collector is > moving around > >>(and probably even freeing) some of the coordinate arrays, > because they > >>are neither pinned or copied. Is this assumption correct? > >> > > > > It's hard to tell what the GLU tesselator is doing under the hood > > from looking at its man pages. If it is holding a pointer to the > > passed GLdouble* then you could be correct. An easier way to > > determine whether this is the problem is to run with -XX:+PrintGC > > (HotSpot only) or -verbose:gc (any JVM, I think). If you see GC > > messages at the times when the vetices are corrupted then this is > > the problem. Otherwise it could be a bug in your application or > > possibly in GL4Java. > > > > > >>If it is correct will this be fixed any time soon? I know that > >>the problem can be resolved by using direct buffers, but i > >>would like to have pre 1.4 compatibility. > >> > > > > There is no good solution for this kind of problem on earlier > > JDKs. Alternatives include performing a data copy via JNI (which > > requires an associated free somewhere, which is sometimes hard to > > figure out when to do, or having a static data buffer, which > > requires synchronization) or performing pinning, which is > > complicated or impossible depending on the GC algorithm. > > > > > > > > > --__--__-- > > Message: 4 > From: Sven Goethel <sgo...@ja...> > Organization: Jausoft - Sven Goethel Software Development > To: Pepijn Van Eeckhoudt <pep...@lu...>, > gl4...@li... > Subject: Re: [gl4java-usergroup] GC Bug > Date: Tue, 8 Jan 2002 19:55:40 +0100 > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 08 January 2002 18:02, Pepijn Van Eeckhoudt wrote: > > In the red book (1.2 third edition) on page 482 second > paragraph, it is > > stated that only a pointer is kept inside the tesselator :). The > > tesselator kicks in when you call glTessEndPolygon. My > suggestion would > > be to copy the data that is passed in glTessVertex calls, > and to free it > > after glTessEndPolygon has returned. I modified my program > so it uses > > direct buffers and this works fine. If I keep the exact > same code, but > > pass a double[] it's messed up again, so the problem isn't > in my program. > > > > Pepijn Van Eeckhoudt > > thx .. > > for the next future, we need to support many more NIO Buffer > functions, true ! > > so you are welcome to add such NIO support to the manuall coded one, > like you suggested e.g. for GLU functions .. > > you can find such manual codes within the GL4Java/C2J/manual > directory ! > > then we need some new functions within the: > gl4java/GLUFunc14.java (interface) > C2J/manual/glu-manualCodedVirt-14.java (manual part) > > gl4java/GLUFunc14JauJNI.java (implementation - JNI > declarations and stubs ..) > C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) > > CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) > C2J/manual/glu-manualCodedImplJNI14.c (manual part) > > just have a look - and understand, how it is done within the > manual GLFunc14* counterpart of the NV extension ..: > > GL4Java/C2J/manual: > gl-manualCodedImplJNI1-14.java > gl-manualCodedImplJNI14.c gl-manualCodedVirt1-14.java > > we might want to make the memory managment functions more > general purpose, > so we can use them for e.g. (as you suggested) > - glTessVertex > - we should create a native NIO buffer which > will be used .., > straight outta the java application, > or by a new general purpose GL4Java utility function .. > > - all passed NIO buffers might be freed by the > glTessEndPolygon function > or by another one .. if allocated by a GL4Java > utility function > > - glTessEndPolygon > - might free all passed NIO buffers, if > allocated by a GL4Java utility function > > so this little concept - please review and make it more clean RFC .., > might be introduced to all OpenGL functions which handles a > big amount of data, > e.g. textures etc., where the JVM's GC might moves or cleans > the memory .. > > cheers, sven > - -- > health & wealth > mailto:sgo...@ja... > www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ > voice : +49-521-2399440 ; fax : +49-521-2399442 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iD8DBQE8O0CsHdOA30NoFAARAkiaAJsGztRzxtMEUGAV4laLTBPGvr4ObQCghN3Z > 49ejsxPlH7Z2+x8o22MLimE= > =08nL > -----END PGP SIGNATURE----- > > > > --__--__-- > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > > End of gl4java-usergroup Digest > ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** |
|
From: Pepijn V. E. <pep...@lu...> - 2002-01-09 09:39:34
|
1. It depends on where you keep the pointer, in java or in c. If you keep a pointer in java it won't make any difference. I'm working on keeping a pointer in the c code. (or at least trying ;)) The problem lies in the way arrays are referenced in the C code. A pointer to the array is retrieved using GetPrimitiveArrayCritical, this pointer is then used for the opengl call, and then the array is released again. This means that the data the pointer refers to is not locked when the jni call returns (in my case gluTessVertex). When the java gc runs, it won't mark the data as garbage if I keep a reference to it in java, BUT this doesn't mean that the location of the data in memory will not change (see mark & sweep gc). The pointer that opengl got during the jni call however will still refer to the old memory location where there might now be random data. What is necessary to fix this is to keep a native copy of the data and use a pointer to this native copy instead of a pointer to the java object. This raises the problem of finding the right time to free the native copy. 2. This would work (I think) , but creating a display list for code that runs only once seems like unnecessary overhead. Also this is just a workaround. What I'm looking for is a way to fix the problem, so you don't need workarounds. The opengl code by itslef is correct so (imho) it should work with gl4java without workarounds. Pepijn Van Eeckhoudt pet...@ba... wrote: > > Are there not two simple solutions to this problem: > > - You could maintain a pointer to the array yourself. Then the stuff > wouldn't get GC'd in the first place. > - You could stick your call to gluTessVertex in a display list. Then the > garbage collector can let itself > loose on the array as much as it likes, cos the data will be > (effectively) server-side by then. > > Or am I missing something here? > > Pete > > > > >>-----Original Message----- >>From: gl4...@li... >>[mailto:gl4...@li...] >>Sent: Tuesday, January 08, 2002 8:10 PM >>To: gl4...@li... >>Cc: gl4...@li... >>Subject: gl4java-usergroup digest, Vol 1 #323 - 4 msgs >> >> >> *** WARNING *** >> >>This mail has originated outside your organization, >>either from an external partner or the Global Internet. >> Keep this in mind if you answer this message. >> >> >>Send gl4java-usergroup mailing list submissions to >> gl4...@li... >> >>To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup >>or, via email, send a message with subject or body 'help' to >> gl4...@li... >> >>You can reach the person managing the list at >> gl4...@li... >> >>When replying, please edit your Subject line so it is more specific >>than "Re: Contents of gl4java-usergroup digest..." >> >> >>Today's Topics: >> >> 1. GC Bug (Pepijn Van Eeckhoudt) >> 2. Re: GC Bug (Kenneth B. Russell) >> 3. Re: GC Bug (Pepijn Van Eeckhoudt) >> 4. Re: GC Bug (Sven Goethel) >> >>--__--__-- >> >>Message: 1 >>Date: Tue, 08 Jan 2002 16:33:33 +0100 >>From: Pepijn Van Eeckhoudt <pep...@lu...> >>To: gluser <gl4...@li...> >>Subject: [gl4java-usergroup] GC Bug >> >>While using the GLU tesselator with 700+ points, I encountered very >>peculiar behavior. Above a certain amount of points, the end >>result of >>the tesselation would be completely messed up. After reading the >>comments in the Nvidia/DirectBuffer demo about the GC bug, I >>took a look >>at the native code that handles a gluTessVertex call and >>found that no >>copy is made of the data that is passed to this function. The OpenGL >>manual states that a call to gluTessVertex only keeps a >>pointer to the >>data array and does not make a copy itself. I assume that what's >>happening in my program is that the garbage collector is >>moving around >>(and probably even freeing) some of the coordinate arrays, >>because they >>are neither pinned or copied. Is this assumption correct? If it is >>correct will this be fixed any time soon? I know that the >>problem can be >>resolved by using direct buffers, but i would like to have pre 1.4 >>compatibility. >> >>Pepijn Van Eeckhoudt >> >> >> >>--__--__-- >> >>Message: 2 >>Date: Tue, 8 Jan 2002 11:50:36 -0500 (EST) >>To: Pepijn Van Eeckhoudt <pep...@lu...> >>CC: gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>From: "Kenneth B. Russell" <kbr...@al...> >>Reply-to: kbr...@al... >> >> >> >>>While using the GLU tesselator with 700+ points, I encountered very >>>peculiar behavior. Above a certain amount of points, the >>> >>end result of >> >>>the tesselation would be completely messed up. After reading the >>>comments in the Nvidia/DirectBuffer demo about the GC bug, >>> >>I took a look >> >>>at the native code that handles a gluTessVertex call and >>> >>found that no >> >>>copy is made of the data that is passed to this function. >>> >>The OpenGL >> >>>manual states that a call to gluTessVertex only keeps a >>> >>pointer to the >> >>>data array and does not make a copy itself. I assume that what's >>>happening in my program is that the garbage collector is >>> >>moving around >> >>>(and probably even freeing) some of the coordinate arrays, >>> >>because they >> >>>are neither pinned or copied. Is this assumption correct? >>> >>It's hard to tell what the GLU tesselator is doing under the hood >>from looking at its man pages. If it is holding a pointer to the >>passed GLdouble* then you could be correct. An easier way to >>determine whether this is the problem is to run with -XX:+PrintGC >>(HotSpot only) or -verbose:gc (any JVM, I think). If you see GC >>messages at the times when the vetices are corrupted then this is >>the problem. Otherwise it could be a bug in your application or >>possibly in GL4Java. >> >> >>>If it is correct will this be fixed any time soon? I know that >>>the problem can be resolved by using direct buffers, but i >>>would like to have pre 1.4 compatibility. >>> >>There is no good solution for this kind of problem on earlier >>JDKs. Alternatives include performing a data copy via JNI (which >>requires an associated free somewhere, which is sometimes hard to >>figure out when to do, or having a static data buffer, which >>requires synchronization) or performing pinning, which is >>complicated or impossible depending on the GC algorithm. >> >> >>--__--__-- >> >>Message: 3 >>Date: Tue, 08 Jan 2002 18:02:15 +0100 >>From: Pepijn Van Eeckhoudt <pep...@lu...> >>CC: gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>To: gl4...@li... >> >>In the red book (1.2 third edition) on page 482 second >>paragraph, it is >>stated that only a pointer is kept inside the tesselator :). The >>tesselator kicks in when you call glTessEndPolygon. My >>suggestion would >>be to copy the data that is passed in glTessVertex calls, and >>to free it >>after glTessEndPolygon has returned. I modified my program so it uses >>direct buffers and this works fine. If I keep the exact same >>code, but >>pass a double[] it's messed up again, so the problem isn't in >>my program. >> >>Pepijn Van Eeckhoudt >> >>Kenneth B. Russell wrote: >> >> >>>>While using the GLU tesselator with 700+ points, I encountered very >>>>peculiar behavior. Above a certain amount of points, the >>>> >>end result of >> >>>>the tesselation would be completely messed up. After reading the >>>>comments in the Nvidia/DirectBuffer demo about the GC bug, >>>> >>I took a look >> >>>>at the native code that handles a gluTessVertex call and >>>> >>found that no >> >>>>copy is made of the data that is passed to this function. >>>> >>The OpenGL >> >>>>manual states that a call to gluTessVertex only keeps a >>>> >>pointer to the >> >>>>data array and does not make a copy itself. I assume that what's >>>>happening in my program is that the garbage collector is >>>> >>moving around >> >>>>(and probably even freeing) some of the coordinate arrays, >>>> >>because they >> >>>>are neither pinned or copied. Is this assumption correct? >>>> >>>> >>>It's hard to tell what the GLU tesselator is doing under the hood >>>from looking at its man pages. If it is holding a pointer to the >>>passed GLdouble* then you could be correct. An easier way to >>>determine whether this is the problem is to run with -XX:+PrintGC >>>(HotSpot only) or -verbose:gc (any JVM, I think). If you see GC >>>messages at the times when the vetices are corrupted then this is >>>the problem. Otherwise it could be a bug in your application or >>>possibly in GL4Java. >>> >>> >>> >>>>If it is correct will this be fixed any time soon? I know that >>>>the problem can be resolved by using direct buffers, but i >>>>would like to have pre 1.4 compatibility. >>>> >>>> >>>There is no good solution for this kind of problem on earlier >>>JDKs. Alternatives include performing a data copy via JNI (which >>>requires an associated free somewhere, which is sometimes hard to >>>figure out when to do, or having a static data buffer, which >>>requires synchronization) or performing pinning, which is >>>complicated or impossible depending on the GC algorithm. >>> >>> >>> >> >> >> >>--__--__-- >> >>Message: 4 >>From: Sven Goethel <sgo...@ja...> >>Organization: Jausoft - Sven Goethel Software Development >>To: Pepijn Van Eeckhoudt <pep...@lu...>, >> gl4...@li... >>Subject: Re: [gl4java-usergroup] GC Bug >>Date: Tue, 8 Jan 2002 19:55:40 +0100 >> >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On Tuesday 08 January 2002 18:02, Pepijn Van Eeckhoudt wrote: >> >>>In the red book (1.2 third edition) on page 482 second >>> >>paragraph, it is >> >>>stated that only a pointer is kept inside the tesselator :). The >>>tesselator kicks in when you call glTessEndPolygon. My >>> >>suggestion would >> >>>be to copy the data that is passed in glTessVertex calls, >>> >>and to free it >> >>>after glTessEndPolygon has returned. I modified my program >>> >>so it uses >> >>>direct buffers and this works fine. If I keep the exact >>> >>same code, but >> >>>pass a double[] it's messed up again, so the problem isn't >>> >>in my program. >> >>>Pepijn Van Eeckhoudt >>> >>thx .. >> >>for the next future, we need to support many more NIO Buffer >>functions, true ! >> >>so you are welcome to add such NIO support to the manuall coded one, >>like you suggested e.g. for GLU functions .. >> >>you can find such manual codes within the GL4Java/C2J/manual >>directory ! >> >>then we need some new functions within the: >> gl4java/GLUFunc14.java (interface) >> C2J/manual/glu-manualCodedVirt-14.java (manual part) >> >> gl4java/GLUFunc14JauJNI.java (implementation - JNI >>declarations and stubs ..) >> C2J/manual/glu-manualCodedImplJNI1-14.java (manual part) >> >> CNativeCode/OpenGLU_JauJNI14_funcs.c (native implementation) >> C2J/manual/glu-manualCodedImplJNI14.c (manual part) >> >>just have a look - and understand, how it is done within the >>manual GLFunc14* counterpart of the NV extension ..: >> >>GL4Java/C2J/manual: >> gl-manualCodedImplJNI1-14.java >>gl-manualCodedImplJNI14.c gl-manualCodedVirt1-14.java >> >>we might want to make the memory managment functions more >>general purpose, >>so we can use them for e.g. (as you suggested) >> - glTessVertex >> - we should create a native NIO buffer which >>will be used .., >> straight outta the java application, >> or by a new general purpose GL4Java utility function .. >> >> - all passed NIO buffers might be freed by the >>glTessEndPolygon function >> or by another one .. if allocated by a GL4Java >>utility function >> >> - glTessEndPolygon >> - might free all passed NIO buffers, if >>allocated by a GL4Java utility function >> >>so this little concept - please review and make it more clean RFC .., >>might be introduced to all OpenGL functions which handles a >>big amount of data, >>e.g. textures etc., where the JVM's GC might moves or cleans >>the memory .. >> >>cheers, sven >>- -- >>health & wealth >>mailto:sgo...@ja... >>www : http://www.jausoft.com ; pgp: http://www.jausoft.com/gpg/ >>voice : +49-521-2399440 ; fax : +49-521-2399442 >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v1.0.6 (GNU/Linux) >>Comment: For info see http://www.gnupg.org >> >>iD8DBQE8O0CsHdOA30NoFAARAkiaAJsGztRzxtMEUGAV4laLTBPGvr4ObQCghN3Z >>49ejsxPlH7Z2+x8o22MLimE= >>=08nL >>-----END PGP SIGNATURE----- >> >> >> >>--__--__-- >> >>_______________________________________________ >>gl4java-usergroup mailing list >>gl4...@li... >>https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup >> >> >>End of gl4java-usergroup Digest >> >> > > > > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > _______________________________________________ > gl4java-usergroup mailing list > gl4...@li... > https://lists.sourceforge.net/lists/listinfo/gl4java-usergroup > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X