>>>>> "Andrew" == Andrew Overholt <overholt@xxxxxxxxxx> writes: Andrew> 1. checkouts of large-ish projects (GNU Classpath is something Andrew> I've used as a test case) get "stuck" at about 83% Andrew> finished. This is about the best information I have at Andrew> this point, but tests with combinations of stock FC4 gcc Andrew> (4.0.0-8, I believe) and stock FC4 Eclipse (3.1.0.M6.22 or Andrew> something like that) or rawhide gcc (4.0.1-x) and rawhide Andrew> Eclipse (3.1.0_fc-2) would be greatly appreciated. If we Andrew> can narrow down when this problem occurred, it would help Andrew> in finding its cause. I don't remember this happening with Andrew> what we had around FC4 release time. Also, does CVS Andrew> compression level affect this? Have you tried this with a proprietary jdk? I spent a little time today debugging this. I didn't see an actual deadlock -- I just saw the code paths in Eclipse taking a long, long time. In particular I think that the TimeoutInputStream stuff we talked about on irc is a red herring... I think those just remain live until the cvs connection is shut down. I saw read() hanging and ssh still running; if the cvs server had shut down the connection I suppose I would expect to see ssh dead (or as a zombie). Instead I did 'thread apply all bt' and looked for other threads doing work for the team plugin. One thread was in org.eclipse.team.internal.ccvs.core.resources.EclipseFolder.isModified. I went to this thread and did 'fini' a lot to see what was happening (I had to ignore SIGHUP so that gdb wouldn't lose my place). Anyway, what I observed here is that some of the 'fini's took a long time, as eclipse went over every resource in a directory (and every subdirectory recursively) making sure that no resource was modified. Anyway, I say all this just in case somebody wants to try to reproduce it, or knows something more that would invalidate my theory, or whatever. If a VM other than gcj does this quickly, then the next thing to look at is where we might be inefficient here. Unfortunately I don't have an up-to-date oprofile-ready machine atm. Tom
