[fedora-java] Eclipse + CVS issues

[Tom Tromey]

>>>>> "Andrew" == Andrew Overholt <overholt at redhat.com> 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