Re: [gl4java-usergroup] GC Bug

[Pepijn V. E. <pep...@lu...>]

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