Geek

My mailbox gets full frequently despite constant archiving. I check the folder size using my mailbox properties to help me clear the problem areas since it shows the distribution of the data amongst the server folders. Most folders get cleared out, but one area that starts to build up over time in my Server Data’s folder list is the “Sync Issues\Conflicts”, which I could not clear.

Today I finally found the folder in “Go > Folder List > (left navigation panel)”, and managed to clear it out. To go back to the original folders, click “Go > Mail”.

Chrome restores all tabs when it is closed and reopened. This has been very useful for me but I got greedy. I now have multiple windows, with each window on a topic I’m search on. E.g. a window with tabs on different hotels and another window with tabs on day trips.

No perfection, but I found that Ctrl-Shift-D will bookmark all tabs into a bookmark folder, and right-clicking on a bookmark folder allows me to open all bookmarks in a bookmark folder to a new window.

Good enough for me.

Oddly this only happens once after the computer is restarted each time. Subsequently the loading would be much quicker.

Using the profiler the following stack trace is obtained:

main [RUNNABLE, IN_NATIVE] CPU time: 0:00
java.io.WinNTFileSystem.list(File)
java.io.File.list()
sun.security.provider.SeedGenerator$1.run()
java.security.AccessController.$$YJP$$doPrivileged(PrivilegedAction)
java.security.AccessController.doPrivileged(PrivilegedAction)
sun.security.provider.SeedGenerator.getSystemEntropy()
sun.security.provider.SecureRandom.engineNextBytes(byte[])
java.security.SecureRandom.nextBytes(byte[])
java.security.SecureRandom.next(int)
java.util.Random.nextLong()
java.io.File.generateFile(String, String, File)
java.io.File.createTempFile(String, String, File)
org.eclipse.core.runtime.adaptor.LocationManager.canWrite(File)
org.eclipse.core.runtime.adaptor.LocationManager.computeDefaultConfigurationLocation()
org.eclipse.core.runtime.adaptor.LocationManager.initializeLocations()
org.eclipse.core.runtime.adaptor.EclipseStarter.startup(String[], Runnable)
org.eclipse.core.runtime.adaptor.EclipseStarter.run(String[], Runnable)
sun.reflect.NativeMethodAccessorImpl.invoke0(Method, Object, Object[])
sun.reflect.NativeMethodAccessorImpl.invoke(Object, Object[])
sun.reflect.DelegatingMethodAccessorImpl.invoke(Object, Object[])
java.lang.reflect.Method.invoke(Object, Object[])
org.eclipse.equinox.launcher.Main.invokeFramework(String[], URL[])
org.eclipse.equinox.launcher.Main.basicRun(String[])
org.eclipse.equinox.launcher.Main.run(String[])
org.eclipse.equinox.launcher.Main.main(String[])

The main thread is stuck in a native File.list() method. From the SeedGenerator source code, there is only one location where it calls the File.list() method, and it happens to match the stack trace — inside an anonymous inner class. From there we can see that it is trying to list the temp folder (system property java.io.tmpdir). On Windows, this is the “%USERPROFILE%\Local Settings\Temp” folder.

When I do a directory listing on the folder, I get more than 100,000 temp files. Removing them solves the problem.

From the stack trace Eclipse startup was trying to test whether a folder is writable, by creating a temporary file, which uses a random number generator to generate the filename, in turn using the list of filenames from the TEMP folder as part of the seed. Essentially this problem would surface if you have a TEMP folder with many many files (regardless of size) and perform any of the following:

• use File.list() on the folder (or any folder with many many files)
• generate a random number
• Create a temporary file
• Starting up Eclipse runtime…

Does Windows cache the directory listing so that it’s faster next time?

We had this deadlock-like behavior where the UI froze sometimes when performing a particular action. But when run with our profiler, it did not report a deadlock when it froze.

After hours of tracing, the cause was identified as an infinite loop on the HashMap.get() method, running in the AWT Event Dispatch thread. The HashMap is the constraints object in a javax.swing.SpringLayout. Why would that happen???

More tracing revealed that there were multiple threads trying to add components to this container, triggering SpringLayout to add new constraints to its map. With reasonable luck the map hits its threshold and tries to resize itself. If you understand hashing you know that this is when it picks a new table size and re-hashes all the objects into its new buckets. When two of this happen at the same time the linked list screws up, and with more luck a later element in the link list points to the next element which is earlier in the same list. The worse part is this is a hidden problem, it doesn’t “surface” until you try to get() an object that’s even later than the later element, that’s when it iterates the bucket past the later element, back to the earlier element, and repeats.

The typical solution to swap the HashMap for a Hashtable is not available here, because the map exists in the core JDK. So it’s a good time to re-iterate to the team the significance of “single threaded model” of AWT/Swing. To be explicit, this issue was resolved by queuing the adding of components to the container on the Event Dispatch thread. Of course a more direct approach would be to synchronize the points where the components were added, but you shouldn’t be doing such things outside the AWT Event Dispatch thread anyway.

When I googled about the HashMap.get() infinite loop I realize it occurs in other areas as well, e.g. a Servlet’s session may be represented as a HashMap. Concurrent put()s and then a get() can cause the same problem.

tried to search for the question mark in Excel but it is treated as a wildcard instead.

Found that the escape char in Excel is ~. Which means “~?” to find a question mark, and “~~” to find a tilde.

http://support.microsoft.com/?kbid=214138