Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 19:50:56 GMT, Sergey Bylokhov wrote: >>> >>> My point is that this is not a test bug, so the test should not be changed. >> >> The test never dispose of the frame. Why is it expected to shut down the >> toolkit? Shall the frame be disposed of when the main thread in the test >> finishes? > >> The test never dispose of the frame. Why is it expected to shut down the >> toolkit? Shall the frame be disposed of when the main thread in the test >> finishes? > > The shutdown is caused by the System.exit call while the toolkit active, so > we should shut down it before the end. It seems "m_breakMessageLoop" is never true for unsuccessful run even though AwtToolkit::QuitMessageLoop finish execution (where m_breakMessageLoop is set to true), so AwtToolkit::MessageLoop never ends, seems to be some timing issue. - PR: https://git.openjdk.java.net/jdk/pull/2220
RFR: 8260616: Removing remaining JNF dependencies in the java.desktop module
This completes the desktop module JNF removal * remove -framework JavaNativeFoundation from make files * remove #import from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S * replace JNFNSToJavaString with NSStringToJavaString and JNFJavaToNSString with JavaStringToNSString * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this) * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods. * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed. * Remove the single usage of JNFPerformEnvBlock * replace JNFJavaToNSNumber in single A11Y file with local replacement * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION) - Commit messages: - 8260616: Removing remaining JNF dependencies in the java.desktop module Changes: https://git.openjdk.java.net/jdk/pull/2305/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8260616 Stats: 431 lines in 71 files changed: 196 ins; 96 del; 139 mod Patch: https://git.openjdk.java.net/jdk/pull/2305.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305 PR: https://git.openjdk.java.net/jdk/pull/2305
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 12:02:54 GMT, Alexey Ivanov wrote: > The test never dispose of the frame. Why is it expected to shut down the > toolkit? Shall the frame be disposed of when the main thread in the test > finishes? The shutdown is caused by the System.exit call while the toolkit active, so we should shut down it before the end. - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 11:57:06 GMT, Alexey Ivanov wrote: >> It seems in successful run, when the test finish >> - AwtToolkit::MessageLoop starts >> - DoQuitMessageLoop is called >> - AwtToolkit::QuitMessageLoop starts >> - AwtToolkit::QuitMessageLoop finishes >> - AwtToolkit::MessageLoop finish >> - Dispose() is called, m_isDisposed sets to true >> - shutdown hook isDisposed is true so no infinite loop >> >> During unsuccessful run, >> - AwtToolkit::MessageLoop starts >> - DoQuitMessageLoop is called >> - AwtToolkit::QuitMessageLoop starts >> - AwtToolkit::QuitMessageLoop finishes >> - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so >> m_isDisposed is not set to true so shutdown hook goes in infinite loop. > > I was looking at the code yesterday. Could it be because of synchronisation? > I mean, do we need to use native synchronisation to guarantee variable > changes are seen across the threads? > > Does MessageLoop not receive Quit / Null message? > > My point is that this is not a test bug, so the test should not be changed. The test never dispose of the frame. Why is it expected to shut down the toolkit? Shall the frame be disposed of when the main thread in the test finishes? - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 09:59:22 GMT, Prasanta Sadhukhan wrote: >> Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff >> should be done to properly shutdown the toolkit. This Dispose() method is >> executed immediately when we exit the message loop in the >> "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is >> executed we should have the message loop, then we call tk.QuitMessageLoop to >> stop it, and wait until all code in the Dispose() is executed. But since the >> IsDisposed() return false we for unknow reason hang, does it mean that the >> message loop still operates? Or we got some error during "QuitMessageLoop"? > > It seems in successful run, when the test finish > - AwtToolkit::MessageLoop starts > - DoQuitMessageLoop is called > - AwtToolkit::QuitMessageLoop starts > - AwtToolkit::QuitMessageLoop finishes > - AwtToolkit::MessageLoop finish > - Dispose() is called, m_isDisposed sets to true > - shutdown hook isDisposed is true so no infinite loop > > During unsuccessful run, > - AwtToolkit::MessageLoop starts > - DoQuitMessageLoop is called > - AwtToolkit::QuitMessageLoop starts > - AwtToolkit::QuitMessageLoop finishes > - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so > m_isDisposed is not set to true so shutdown hook goes in infinite loop. I was looking at the code yesterday. Could it be because of synchronisation? I mean, do we need to use native synchronisation to guarantee variable changes are seen across the threads? Does MessageLoop not receive Quit / Null message? - PR: https://git.openjdk.java.net/jdk/pull/2220
Re: RFR: 8197825: [Test] Intermiitent timeout with javax/swing JColorChooser Test [v3]
On Thu, 28 Jan 2021 05:53:05 GMT, Sergey Bylokhov wrote: >> My point is that this is not a test bug, so the test should not be changed. > > Please take a look at the "AwtToolkit::Dispose()" method, on how much stuff > should be done to properly shutdown the toolkit. This Dispose() method is > executed immediately when we exit the message loop in the > "Java_sun_awt_windows_WToolkit_eventLoop". So when the shutdown hook is > executed we should have the message loop, then we call tk.QuitMessageLoop to > stop it, and wait until all code in the Dispose() is executed. But since the > IsDisposed() return false we for unknow reason hang, does it mean that the > message loop still operates? Or we got some error during "QuitMessageLoop"? It seems in successful run, when the test finish - AwtToolkit::MessageLoop starts - DoQuitMessageLoop is called - AwtToolkit::QuitMessageLoop starts - AwtToolkit::QuitMessageLoop finishes - AwtToolkit::MessageLoop finish - Dispose() is called, m_isDisposed sets to true - shutdown hook isDisposed is true so no infinite loop During unsuccessful run, - AwtToolkit::MessageLoop starts - DoQuitMessageLoop is called - AwtToolkit::QuitMessageLoop starts - AwtToolkit::QuitMessageLoop finishes - AwtToolkit::MessageLoop NEVER ends so Dispose() is not called so m_isDisposed is not set to true so shutdown hook goes in infinite loop. - PR: https://git.openjdk.java.net/jdk/pull/2220
