FileChooser creation occasionally hangs about vis-ui

[kotcrab]

I'd blame FileSystemView which is used to get full system names of drives (eg.: 'C:' to 'Local Drive C:') problem is that class is slow, not super slow but still... The names are cached but it is done on creation.

Have you got any external drive connected or floppy disk drive? (really :D) I think that FIleSystemView tries to access those drives and for external drive on standby mode it will make it spin up which takes time, accessing floppy disk drive is probably even worse even without inserted disk.

If that is really it, I see two solutions: check if drive is external/floppy and don't get name for it or move getting names to another thread.

Change this line https://github.com/StrongJoshua/VisEditor/blob/master/UI/src/com/kotcrab/vis/ui/widget/file/FileChooser.java#L504 to displayName = ""; and test, currently there is no other way to disable it. Also any stacktrace when it crashes and what OS are you using?

[StrongJoshua]

Haha floppies :P Sorry that I forgot to mention my relevant comp specs.

Windows 7
Intel i7 3770k
120 GB SSD (for OS)
1 TB HDD (everything else, essentially)

I don't have any external drives, both those drives are internal. But actually (I'm writing this after writing the rest of the post), now that I think about it, there is another drive connected to my computer. It is the drive contained in an Apple Airport unit (I use it as a router and occasional file storage). Do you think that could be an issue?

This is a hard thing to test, since it does not happen all the time, but even after changing the line you specified there was still a major difference between the loading time of everything else and the file chooser:

before instantiate 1432504151241
before file chooser 1432504151251
after file chooser 1432504151391
before editor 1432504151391
after editor 1432504151433
after instantiate 1432504151433

As you can see, the time caused by the file chooser is still about 3.5 times as long as the biggest other gap.
Here is another try with the line changed back to normal:

before instantiate 1432504438431
before file chooser 1432504438444
after file chooser 1432504438660
before editor 1432504438660
after editor 1432504438725
after instantiate 1432504438725

Here the gap is 216ms. More than without fetching the displayName, but not too much.

[kotcrab]

I did some more detailed profiling, here are the results:

As you can see the slowest things are file operations: getting system name and checking whether a file is directory. It's almost 100% time spent on chooser creation, I guess not much we can do here, file operations are just slow.

If you have that network drive mounted and you can access it in chooser then maybe it is causing this, but still 17 seconds is ridiculous... you said that is happens often after launching Eclipse, maybe the first access is very slow because Windows hasn't connected to that drive or something, I'm not sure.
I currently don't have any options to test it with network drives.

How often does it happen? Does it happen every time you reboot your PC? I know it's hard to test but that is probably our only option ;)

[StrongJoshua]

Usually it would happen if I just started my computer, opened Eclipse, and immediately chose to open my app's map editor. I'll give you more information about exactly what was going on when it happens next time.

Yeah, 17 seconds is a bit much and I usually end up force closing the app when it takes longer than about 7 seconds. Once I try it again, it only takes on average 1 second or so.

How did you get that profiling view that shows how long each process takes? Is that part of Eclipse?

[kotcrab]

It's part of NetBeans, only reason why I installed it :P I know there is also VisualVM profiler, similar to NetBeans. There is some way to install profiler in Eclipse but last time I tried it wasn't working for me.

[StrongJoshua]

I just happened again. My computer was in sleep mode, I woke it up, and ran my app (Eclipse was already open before I put my comp to sleep).
Output:

before instantiate 1432578311969
before file chooser 1432578311979
after file chooser 1432578329785
before editor 1432578329785
after editor 1432578329826
after instantiate 1432578329826

Once again, around 17-18 seconds. It could just be the file system being very slow to start up. So I don't know if there is anything in your power to fix this.

[kotcrab]

Were you using chooser with that changed line (displayName = "";) when it happened?

[StrongJoshua]

No, I had reverted it back to normal, but I'll change it to that and let you know if it happens again.

[kotcrab]

That would be great. If it still happens after changing that line then I don't have any idea how to fix it.

[code-disaster]

We are watching similar effects. On my MacBook everything's smooth and fast, but on a Surface 3 Pro the FileChooser window has a noticeable delay when opened. The Surface has an additional SD card mounted. My assumption is that FileChooser.rebuildFileRootsCache() takes a long time to (potentially wake up, then) scan all drives.

If that's right, I'm not sure yet how to resolve it. If the initial File.listRoots() doesn't cause the delay already, it might be possible to just add a user-defined filter to ignore roots.

An other option I didn't try yet is to cache and reuse FileChooser instances. Right now I recreate them every time.

[kotcrab]

From what I tested File.listRoots is fast (it doesn't even show in profiling), the problem lies in FileSystemView#getSystemDisplayName.

My only idea to fix is to move getting those names to another thread, so main won't be blocked if some drive is sleeping. I don't want to drop this feature, seeing full drive name instaed of for example: "C:" is a lot better. Though this applies only to Windows, on Linux (and OS X?) there is usually one root: "" (in 0.7.7 displayed as "Computer").

User-defined filter isn't good solution, it won't work if you run your app on another computer.

The chooser should be always reused whenever possible, definitely don't create new one every time user clicked "Chooser file" button. Two reasons: even if everything works fast as expected the creation delay is still noticeable and when you are reusing instance the chooser remembers last opened folder, very important thing for UX imo. In my app I have one instance per entire application.

[kotcrab]

I moved getting names to another thread, I'm still looking how to further optimize chooser. The slow initialization time is also caused by obtaining desktop directory path, doing it loads some stuff from AWT. I'm looking now how I can avoid that.

@StrongJoshua @code-disaster
You can try those changes in 0.8.0-SNAPSHOT, I'd consider them as beta and I tested them only on Windows.

[kotcrab]

I've made some additional changes and tested them on Fedora. System names are now retrieved only on Windows, I didn't found a way to avoid loading AWT Toolkit but it's done on another thread and only once so no big deal.

It'd be great if you could provide some feedback after testing so I will now if that fixed this issue.

[StrongJoshua]

Yeah, I'll let you know how's going after a couple days of using it!

[StrongJoshua]

UPDATE This patch looks promising. Even after just turning my computer and Eclipse on after a night of being off (which is usually when the hang was the worst) I got the following results:

before instantiate 1432989343306
before file chooser 1432989343393
after file chooser 1432989343891
before editor 1432989343891
after editor 1432989344519
after instantiate 1432989344519

[kotcrab]

So, looks like this issue is fixed, fell free to reopen if it still occurs.

[ShibaBandit]

Loving the VisUI library so far. I'm using 0.8.1, I think I may be having the same problems on Windows 10 where it takes 4-5 seconds to create a FileChooser. I'm on a fairly modern system (core i7), but I do have an SSD + many HDDs in a server tower.

[kotcrab]

Does it always take 4-5 seconds to create it (every time you launch your app)?

[ShibaBandit]

@kotcrab Yes sir, each time I create a FileChooser instance on the Windows machine is takes several seconds. However, on my Macbook 2014 with SSD, it loads instantly every time with no issues.

[kotcrab]

Ok, this might be a different issue, previously it was only happening when one of drive was sleeping.

Do you know how to use profiler? You could profile your app and see what's takes the longest time in FileChooser. I'm not able to reproduce this so I pretty much need your help. If you don't know how to use it then come to our IRC and I'll give you quick tutorial :D

[ShibaBandit]

Sure, I'll profile it and post findings. Won't be at the Windows PC for a bit but I'll post the results when I can.

[ShibaBandit]

Sorry for delay, posted screenshot below of profile using VisualVM:

[kotcrab]

Hmm getSystemDisplayName is executed from different thread but I suspect it may be blocking entire JVM.

One more thing to try, don't create FileChooser and just call FileChooserWinService.getInstance() in VisualVM press Thread Dump button in Threads tab. Make sure you do that when app is still blocked. Post log here.

Though I don't think I will be able to do anything about it, I guess I will just remove getting system drive names from Windows and just show "Drive C:" etc. I really like that functionality so I think I will add some method to set custom name provider. It could utilize WinAPI methods via JNA, though it will have to be optional, not everyone would like to add JNA lib just for that.

[ShibaBandit]

Only calling 'FileChooserWinService.getInstance()' does not appear to take THAT long - 300ms.

Calling new FileChooser(FileHandle, Mode) causes the delay, its thread dump is:

2015-09-01 18:07:54
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.11-b03 mixed mode):

"Swing-Shell" #30 daemon prio=5 os_prio=0 tid=0x000000001ba67800 nid=0x1e9c waiting on condition [0x000000002e45f000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000780307040> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at sun.awt.shell.Win32ShellFolderManager2$ComInvoker$3.run(Win32ShellFolderManager2.java:517)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"AWT-Windows" #27 daemon prio=6 os_prio=0 tid=0x000000001ba69000 nid=0x994 runnable [0x000000002e35f000]
   java.lang.Thread.State: RUNNABLE
    at sun.awt.windows.WToolkit.eventLoop(Native Method)
    at sun.awt.windows.WToolkit.run(WToolkit.java:302)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"Java2D Disposer" #25 daemon prio=10 os_prio=2 tid=0x000000001ba6d800 nid=0x664 in Object.wait() [0x000000002e15e000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
    - locked <0x0000000780176130> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
    at sun.java2d.Disposer.run(Disposer.java:148)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"SystemDisplayNameGetter-2" #24 daemon prio=5 os_prio=0 tid=0x000000001ba68000 nid=0x1484 waiting on condition [0x000000002dd7f000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000780971790> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"SystemDisplayNameGetter-1" #23 daemon prio=5 os_prio=0 tid=0x000000001c908800 nid=0x10c4 waiting on condition [0x000000002d18f000]
   java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x0000000780971790> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
    at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"SystemDisplayNameGetter-0" #22 daemon prio=5 os_prio=0 tid=0x000000001bd2e000 nid=0x1f40 runnable [0x000000002ce6f000]
   java.lang.Thread.State: RUNNABLE
    at java.io.WinNTFileSystem.getBooleanAttributes(Native Method)
    at java.io.File.exists(File.java:819)
    at sun.awt.shell.ShellFolder.getShellFolder(ShellFolder.java:242)
    at com.kotcrab.vis.ui.widget.file.internal.FileChooserWinService.getSystemDisplayName(FileChooserWinService.java:110)
    at com.kotcrab.vis.ui.widget.file.internal.FileChooserWinService.access$000(FileChooserWinService.java:33)
    at com.kotcrab.vis.ui.widget.file.internal.FileChooserWinService$2.run(FileChooserWinService.java:68)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - <0x0000000780928510> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"LWJGL Timer" #21 daemon prio=5 os_prio=0 tid=0x000000001cbf1000 nid=0x2124 waiting on condition [0x000000002840f000]
   java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at org.lwjgl.opengl.Sync$1.run(Sync.java:116)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"RMI TCP Connection(2)-192.168.1.72" #20 daemon prio=5 os_prio=0 tid=0x000000002bdc7000 nid=0x494 runnable [0x00000000282ce000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:150)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    - locked <0x000000078092a6c8> (a java.io.BufferedInputStream)
    at java.io.FilterInputStream.read(FilterInputStream.java:83)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:539)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:812)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:671)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - <0x000000078092a858> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"JMX server connection timeout 19" #19 daemon prio=5 os_prio=0 tid=0x000000002b03d800 nid=0x4ec in Object.wait() [0x00000000281cf000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
    - locked <0x0000000701a426f8> (a [I)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"RMI Scheduler(0)" #18 daemon prio=5 os_prio=0 tid=0x000000002ba7d800 nid=0x1d88 waiting on condition [0x00000000279be000]
   java.lang.Thread.State: TIMED_WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for  <0x00000007019ce0f8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
    at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
    at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
    at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
    at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"RMI TCP Connection(1)-192.168.1.72" #17 daemon prio=5 os_prio=0 tid=0x000000002ba86800 nid=0x7e8 runnable [0x00000000278be000]
   java.lang.Thread.State: RUNNABLE
    at java.net.SocketInputStream.socketRead0(Native Method)
    at java.net.SocketInputStream.read(SocketInputStream.java:150)
    at java.net.SocketInputStream.read(SocketInputStream.java:121)
    at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
    at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
    - locked <0x0000000701a42a88> (a java.io.BufferedInputStream)
    at java.io.FilterInputStream.read(FilterInputStream.java:83)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:539)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:812)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:671)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - <0x0000000701a42c48> (a java.util.concurrent.ThreadPoolExecutor$Worker)

"RMI TCP Accept-0" #16 daemon prio=5 os_prio=0 tid=0x000000001cf60000 nid=0x236c runnable [0x0000000027ece000]
   java.lang.Thread.State: RUNNABLE
    at java.net.DualStackPlainSocketImpl.accept0(Native Method)
    at java.net.DualStackPlainSocketImpl.socketAccept(DualStackPlainSocketImpl.java:131)
    at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:199)
    - locked <0x00000007019d2740> (a java.net.SocksSocketImpl)
    at java.net.ServerSocket.implAccept(ServerSocket.java:545)
    at java.net.ServerSocket.accept(ServerSocket.java:513)
    at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:389)
    at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:361)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000002373800 nid=0x1e90 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"LWJGL Application" #12 prio=5 os_prio=0 tid=0x000000001c96f800 nid=0x2304 runnable [0x000000001da7e000]
   java.lang.Thread.State: RUNNABLE
    at java.io.WinNTFileSystem.checkAccess(Native Method)
    at java.io.File.canRead(File.java:768)
    at com.kotcrab.vis.ui.widget.file.FileChooser.rebuildFileRootsCache(FileChooser.java:529)
    at com.kotcrab.vis.ui.widget.file.FileChooser.rebuildShortcutsList(FileChooser.java:503)
    at com.kotcrab.vis.ui.widget.file.FileChooser.rebuildShortcutsList(FileChooser.java:520)
    at com.kotcrab.vis.ui.widget.file.FileChooser.init(FileChooser.java:189)
    at com.kotcrab.vis.ui.widget.file.FileChooser.<init>(FileChooser.java:122)
    at com.shibabandit.megacopter.editor.McMenuBar$4.clicked(McMenuBar.java:156)
    at com.badlogic.gdx.scenes.scene2d.utils.ClickListener.touchUp(ClickListener.java:89)
    at com.badlogic.gdx.scenes.scene2d.InputListener.handle(InputListener.java:58)
    at com.badlogic.gdx.scenes.scene2d.Stage.touchUp(Stage.java:348)
    at com.badlogic.gdx.InputMultiplexer.touchUp(InputMultiplexer.java:96)
    at com.badlogic.gdx.backends.lwjgl.LwjglInput.processEvents(LwjglInput.java:306)
    - locked <0x0000000700373a70> (a com.badlogic.gdx.backends.lwjgl.LwjglInput)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication.mainLoop(LwjglApplication.java:207)
    at com.badlogic.gdx.backends.lwjgl.LwjglApplication$1.run(LwjglApplication.java:120)

   Locked ownable synchronizers:
    - None

"Monitor Ctrl-Break" #11 daemon prio=5 os_prio=0 tid=0x000000001bcab000 nid=0x920 runnable [0x000000001c75f000]
   java.lang.Thread.State: RUNNABLE
    at java.net.DualStackPlainSocketImpl.accept0(Native Method)
    at java.net.DualStackPlainSocketImpl.socketAccept(DualStackPlainSocketImpl.java:131)
    at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:404)
    at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:199)
    - locked <0x00000007002de660> (a java.net.SocksSocketImpl)
    at java.net.ServerSocket.implAccept(ServerSocket.java:545)
    at java.net.ServerSocket.accept(ServerSocket.java:513)
    at com.intellij.rt.execution.application.AppMain$1.run(AppMain.java:90)
    at java.lang.Thread.run(Thread.java:745)

   Locked ownable synchronizers:
    - None

"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x000000001bafc800 nid=0x11ac runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C1 CompilerThread3" #9 daemon prio=9 os_prio=2 tid=0x000000001ba6c000 nid=0x1598 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread2" #8 daemon prio=9 os_prio=2 tid=0x000000001ba54800 nid=0x250 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread1" #7 daemon prio=9 os_prio=2 tid=0x000000001ba4f800 nid=0x1c80 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"C2 CompilerThread0" #6 daemon prio=9 os_prio=2 tid=0x000000001ba4d800 nid=0x428 waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x000000001ba4c000 nid=0x1aec waiting on condition [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001ba4b000 nid=0xcf4 runnable [0x0000000000000000]
   java.lang.Thread.State: RUNNABLE

   Locked ownable synchronizers:
    - None

"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000000246b000 nid=0x408 in Object.wait() [0x000000001ba1f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    - waiting on <0x0000000700294070> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:142)
    - locked <0x0000000700294070> (a java.lang.ref.ReferenceQueue$Lock)
    at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:158)
    at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)

   Locked ownable synchronizers:
    - None

"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000019a4c000 nid=0x1ad4 in Object.wait() [0x000000001b91f000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:502)
    at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:157)
    - locked <0x000000070029d9b8> (a java.lang.ref.Reference$Lock)

   Locked ownable synchronizers:
    - None

"VM Thread" os_prio=2 tid=0x0000000019a48000 nid=0x12a0 runnable 

"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x000000000238a000 nid=0x82c runnable 

"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x000000000238b800 nid=0x22f4 runnable 

"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x000000000238d000 nid=0x2474 runnable 

"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x000000000238e800 nid=0x20b0 runnable 

"GC task thread#4 (ParallelGC)" os_prio=0 tid=0x0000000002391000 nid=0x2bc runnable 

"GC task thread#5 (ParallelGC)" os_prio=0 tid=0x0000000002392000 nid=0x72c runnable 

"GC task thread#6 (ParallelGC)" os_prio=0 tid=0x0000000002395800 nid=0x12b8 runnable 

"GC task thread#7 (ParallelGC)" os_prio=0 tid=0x0000000002396800 nid=0xf70 runnable 

"VM Periodic Task Thread" os_prio=2 tid=0x000000001bafe800 nid=0x153c waiting on condition 

JNI global references: 293

[intrigus]

Maybe printout the times after different modules of FileChooser are created. So that you know how long each module takes to initialize.

[ShibaBandit]

I did some digging through and figured it out... I thought my issue was the same as others in this post but it is not. Turns out when I migrated to Windows 10 it installed an A:\ drive floppy, even though I don't have a floppy disk drive in my machine. I went into device manager and uninstalled the drive and it goes plenty fast now... If any of you have worked with a floppy drive before, you'll know that probing that type of drive for information like a name can take many seconds, which was causing the slow down.

I think we can probably close this... hope this information was useful and not a complete waste of time.

[kotcrab]

Interesting why it takes so long even when there isn't any floppy drive. Yeah it was useful, this whole issue with hanging it's pretty specific and hard for me to reproduce so every bit of information is helpful.

Looks like the slowdown is caused by file.canRead() but without that I can't add drive to file roots list. I'm thinking about moving it to separate threads, similar like I did with FileChooserWinService.

I could also completely ignore listing and checking A:\ and B:\ drives but who knows maybe there is someone out there will try to use chooser to open file from floppy disk :D

[ShibaBandit]

Yea you could list A:\ and B:\ but skip checks on them such as canRead and getName. I agree it's not the best solution, although using A:\ and B:\ for other volume types is non-standard.

[kotcrab]

That won't do, if drive is connected but there isn't any media in it then it is still listed in File.getRoots(). That's why I need canRead to check if there is something readable in that root. If i skip canRead it would always show up even it's when empty. Yes, it's not standard but unfortunately Windows allows to change drive letter to A:\ or B:. I'm working on threaded solution now.

[kotcrab]

Root checking is multi threaded now, this should fix this issue and also speed up chooser creation.