Hi Petr,
Thanks for the update. The fix looks fine.
--
best regards,
Anthony
On 6/16/2014 3:31 PM, Petr Pchelko wrote:
Hello, Anthony.
Thanks for the review, the new version is here:
http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.01/
I've also made eawt Application start AppKit, I've forgot about this one
initially.
Now I've made a grep over all loadLibrary("awt") usages and is looks like it's
replaced with getDefaultToolkit in all places we need.
With best regards. Petr.
On 03 июня 2014 г., at 17:59, Anthony Petrov <[email protected]> wrote:
Hi Petr,
The fix looks good to me. One minor nit: every file that includes AWT_debug.h
will contain its own copy of the ShouldPrintVerboseDebugging() function and the
debug flag. Could we have only one copy instead?
--
best regards,
Anthony
On 6/3/2014 3:18 PM, Petr Pchelko wrote:
Hello, AWT Team.
Please review a little fix for the issue:
https://bugs.openjdk.java.net/browse/JDK-8033367
The fix is available here:
http://cr.openjdk.java.net/~pchelko/9/8033367/webrev/
The problem:
We were doing too much in JNI_OnLoad. Loading many classes, making sync calls
to Appkit thread, loading classes and native libs from Appkit thread and so on.
This was causing deadlocks and crashes that we've workarounded for 8. But for 9
I've rewritten the AWT startup code to make JNI_OnLoad do a bit less work.
The solution:
Now loading awt native lib does not trigger loading AppKit and starting
NSApplication. Instead we just load a library and tell Cocoa we are going to be
multithreaded.
We start Appkit when Toolkit is created, so now we avoid problems with
deadlocks on runtime lock.
An issue with the fix:
I've made GraphicsEnvironment also load AppKit, because we use an NSView for a
scratch surface in an OpenGL context. Really this is quite likely not needed as
we are
(should be) using FBOs for offscreen rendering. But getting rid of an
NSView-based scratch surface is a separate big project, so I'll file a bug for
it and now let's load
Appkit when GraphicsEnvironment is initialized too.
Testing:
I have run all JCK, all regression tests, sanity-tested JFX interop and SWT
interop, checked applets and webstart, tested headless mode. Everything seems
to work fine,
but anyway this fix is extremely risky. But this should be done if we want to
avoid a problems like JDK-8033367 or JDK-8031050.
Thank you.
With best regards. Petr.
