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