<AWT Dev> [8] Review request for 8015730: PIT: On Linux, OGL=true and fbobject=false leads to deadlock or infinite loop

Anthony Petrov anthony.petrov at oracle.com
Mon Jul 1 04:11:27 PDT 2013


Hi Anton,

I'm not sure if this a good fix since it enabled the GL thread to call 
Xlib APIs w/o acquiring the AWTLock. This may not present a problem 
currently since we know exactly when this method is called and that 
another thread is holding the lock and isn't calling other X11 functions 
at the moment. But I doubt this knowledge will be widely known and 
remembered in the future, and if another thread starts calling X11 
routines, we'll get into trouble...

Why would another thread (the AWT EventQueue if I got the problem right) 
hold the AWTLock and wait till the GL thread finishes its job? I'd 
assume it should release the lock for the period of waiting. This would 
allow the GL thread to acquire the lock and perform the XSync() call w/o 
any potential issues. Have you investigated this option?

--
best regards,
Anthony

On 06/28/2013 09:16 PM, Anton Litvinov wrote:
> Hello,
>
> Could you please review the following fix for a bug, which consists in a
> deadlock provoked by concurrency between AWT-EventQueue and Java2D Queue
> Flusher for taking AWT lock, when OpenGL rendering is enabled.
>
> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015730
> Webrev: http://cr.openjdk.java.net/~alitvinov/8015730/webrev.00
>
> The fix allows the code from the native function
> "Java_sun_java2d_opengl_GLXSurfaceData_initPbuffer" of the file
> "jdk/src/solaris/native/sun/java2d/opengl/GLXSurfaceData.c" execute all
> XError handling procedures using "sun.awt.X11.XErrorHandlerUtil" class
> without acquiring AWT lock. It is the only available solution for this
> problem, because the current design of
> "sun.java2d.opengl.OGLRenderQueue" class does not allow to take AWT lock
> in Java2D Queue Flusher thread without reaching a deadlock, since all
> calls to the method
> "sun.java2d.opengl.OGLRenderQueue.flushAndInvokeNow(Runnable r)" are
> guarded by AWT lock.
>
> Thank you,
> Anton


More information about the awt-dev mailing list