Hello, Sergey. Thank you for the review, great catch. The new version is here: http://cr.openjdk.java.net/~pchelko/9/8033367/webrev.02/
I've grepped the sources, there are no other references to the awt.m file. With best regards. Petr. On 02 июля 2014 г., at 15:08, Sergey Bylokhov <[email protected]> wrote: > Hi, Petr. > Looks like there are some links to the awt.m in the source code. > In the Awt2dLibraries.gmk and in the java_md_macosx.c > > On 02.07.2014 14:58, Petr Pchelko wrote: >> 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. >>>>>> > > > -- > Best regards, Sergey. >
