Hello, Is anyone willing to make a second review?
Thank you. With best regards. Petr. On 16 июня 2014 г., at 22:32, Anthony Petrov <[email protected]> wrote: > 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. >>>> >>
