<AWT Dev> [9] Review Request: 8033367 [macosx] Appletviewer was broken in jdk8 b124

[Sergey Bylokhov]

Hi, Petr.
The fix looks good.

On 02.07.2014 15:20, Petr Pchelko wrote:
> 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 <Sergey.Bylokhov at oracle.com> 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 <anthony.petrov at oracle.com> 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 <anthony.petrov at oracle.com> 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.
>>


-- 
Best regards, Sergey.