Bug 1393 - MacOS 10.14.6 + OpenJDK11U produces occasional freezes on AppKit Main Thread
Summary: MacOS 10.14.6 + OpenJDK11U produces occasional freezes on AppKit Main Thread
Status: IN_PROGRESS
Alias: None
Product: Newt
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2.4.0
Hardware: All macosx
: P4 major
Assignee: Sven Gothel
URL:
Depends on: 1370
Blocks:
  Show dependency treegraph
 
Reported: 2019-09-09 08:54 CEST by Sven Gothel
Modified: 2019-09-11 07:41 CEST (History)
0 users

See Also:
Type: DEFECT
SCM Refs:
b12a80e386b12d9d8fa63cf07124f8da989dcd04 e33aa16904d8abddaeceb1374ffa45bd45a96210 7e76df3a05b7eb2404cb4584ee0b34ea287eb9bf b8db98376069a72ad40b7ef2fe2d9003aea2b091
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2019-09-09 08:54:44 CEST
Latest manual tests after resolving Bug 1389
disclosed a few occasional freezes using NEWT + Java11.

These are related to probable AWT changes since Java8.

MacOS 10.14.6 freezes 4 / 273
====================================
com.jogamp.opengl.test.junit.jogl.acore.ect.TestExclusiveContext01VSyncAnimNEWT test07ExclPre_4Win
com.jogamp.opengl.test.junit.jogl.acore.ect.TestExclusiveContext11VSyncAnimNEWT
com.jogamp.opengl.test.junit.jogl.acore.ect.TestExclusiveContext02FPSAnimNEWT
com.jogamp.opengl.test.junit.jogl.acore.ect.TestExclusiveContext12FPSAnimNEWT

Inspection of proper utilization of NSWindow/NSView etc 
on AppKit Main-Thread is required. 

May utilize 'Main Thread Checker', see
<https://developer.apple.com/documentation/code_diagnostics/main_thread_checker?language=objc>

Further we should align the Main-Thread usage in the macosx implementation
with our new ios implementation.
See commit 004c67c73a0309158c30929cd0d6513e23f34803 
which already simplifies the createWindow code.
Comment 1 Sven Gothel 2019-09-09 09:11:12 CEST
Just for the sake of a little documentation:

We have to ensure avoiding deadlocks the likes of:

Threads: USR, EDT, AppKit
(USR the user thread, any ..)
(EDT the NEWT EDT thread for lifecycle and events/tasks)
(AppKit MacOS APPKit Main-Thread)

USR -- cmd --> EDT (blocking pending action)

from here on:

EDT -- osx --> APK (one of those cocoa/NS actions)

EDT <-- blocking -- APK (we issue a deferred-and-wait NEWT command on EDT)

Result ** DEADLOCK **

The only critical synchronous action w/ NEWT are
lifecycle operations, where we demand handles to be realized.
E.g. createWindow(..) up until the native handles exist,
however, the actual 'setVisible' can be spun off-thread on the APK.
Comment 2 Sven Gothel 2019-09-09 09:39:49 CEST
resolved as described:

commit b12a80e386b12d9d8fa63cf07124f8da989dcd04
Author: Sven Gothel <sgothel@jausoft.com>
Date:   Mon Sep 9 09:29:43 2019 +0200

    Bug 1393: Run orderFront0(=setVisible) async off-thread on AppKit after sync AppKit NSWindow creation
    
    MacOS 10.14.6 + OpenJDK11U produces occasional freezes on AppKit Main Thread
    
    Latest manual tests after resolving Bug 1389
    disclosed a few occasional freezes using NEWT + Java11.
    
    These are related to probable AWT changes since Java8,
    as these do not occur with Java8.
    
    Fix: Spun off orderFront0(=setVisible) async off-thread on AppKit after sync AppKit NSWindow creation.
    
    This fix also aligns the macos createWindow code with the new simplified ios implementation,
    see commit 004c67c73a0309158c30929cd0d6513e23f34803


commit e33aa16904d8abddaeceb1374ffa45bd45a96210
Author: Sven Gothel <sgothel@jausoft.com>
Date:   Mon Sep 9 09:33:23 2019 +0200

    Bug 1393: MacOS/iOS: Issue updateSizePosInsets0 async to AppKit Main-Thread
    
    Additionally, setPointerIcon0 must also be made async on AppKit (instead of wait),
    we have to assume/hope the user won't pull the PointerIconImpl instance in-between ;-)
    Hence removing the comment regarding the lifecycle.


commit 7e76df3a05b7eb2404cb4584ee0b34ea287eb9bf (HEAD -> master)
Author: Sven Gothel <sgothel@jausoft.com>
Date:   Mon Sep 9 09:36:50 2019 +0200

    Bug 1393: OSXUtil: Optionally inject Apple's 'Main Thread Checker'
    
    To allow proper testing of whether all AppKit calls are performed on its Main-Thread where required,
    we inject the libMainThreadChecker.dylib when property 'nativewindow.debug.OSXUtil.MainThreadChecker' is set.
    
    See <https://developer.apple.com/documentation/code_diagnostics/main_thread_checker?language=objc>
    Lib-Name: /Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib
Comment 3 Sven Gothel 2019-09-11 04:18:16 CEST
commit b8db98376069a72ad40b7ef2fe2d9003aea2b091

    Bug 1393: Add window position validation in TestDisplayLifecycle*NEWT
    
    The OSX fixes for bug 1393 spun off certain tasks like position/size gathering async to AppKit,
    hence we should validate whether both are valid.
    
    Further the TestDisplayLifecycle02NEWT had one bug,
    it retrieved 'screen.getViewportInWindowUnits()' while it was not yet initialized.
Comment 4 Sven Gothel 2019-09-11 07:41:51 CEST
reopening: further investigation shows that subsequent 'run on main-thread' task has been spun off to the app-kit thread, but not processed.

however, the app-kit thread has not being locked within our EDT
as shown in comment 1.