Community
Participate
Working Groups
If I cut/copy/paste within a java editor, I can end up waiting a few seconds for eclipse to return control to me. This on a hyperthreaded xeon 2.6Ghz machine with 2 GB of RAM, so I don't think the hardware is the problem. The CPU is pegged during this freeze, and funnily enough KDE is completely unresponsize till I get back control (though I think this is a KDE/java interop issue as I don't have the same problem with gnome) This is very repeatable, and happens with almost every use of of the clipboard commands - If I stay in the same editor, the pauses will sometimes go away, but they come back if I switch to another editor and back. Needless to say, this makes eclipse 3.1M2 unusable, so I've switched back to 3.0.1 I run eclipse with like "/opt/eclipse/eclipse -data /home/conway/eclipse-config/workspace -vmargs -Xmx512M", and this failue occurs even on a clean eclipse install (no plugins, no workspace and no ~/.eclipse)
see: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-text-home/development/bug-incomplete.htm In addition: - how big is the file? - how big is the selection that you copy?
build eclipse 3.1M2 Fedora linux core 2 jdk build 1.4.2_04-b05 The problem occurs regardless of the size of the file or the size of the selection. It happens on a stock eclipse 3.1M2 install - that is I removed ~/.eclipse and used a new workspace. All I do is import an existing project into that workspace. I don't change any of the default eclipse settings. It does not happen when I use clipboard from a simple project, but does when I use from the complex project I imported. This complex project has about 200 source folders. If I remove all but one, then the problem seems to go away, so it looks like a scalability issue w.r.t. the number of source folders in a project Elcipse 3.0.0/1 doesn't have this problem.
The link in comment 1 explains how to create VM dumps. We need those to see where the time is spent. How much memory do you give to eclipse (-vmargs ...)? Anything in .log?
Nothing in log -vmargs -Xmx512m Attaching a dump taken while eclipse was frozen waiting for the ctrl-c to complete.
Created attachment 15140 [details] trace of frozen eclipse after ctrl-c op
Do you see this after startup or after working for a quite a while?
The trace shows that the AST is created where it shouldn't.
It is OK that the AST is created here: if cut is hit in a situation where reconciling was in progress the reconciling gets cancelled and ast=null returned instead. The AST provider needs to set the cache to null because otherwise a wrong AST would be returned. The AST has to be created and returned.
Did you use copy or cut for the attached VM dump? Could you provide an additional dump?
Most likely related to bug 76377.
This happens very soon after startup Not always immediately, but within a few operations. That is, I duplicate it with a clean workspace, so I have nothing to work on, so it has happen pretty quick to keep my interest =) I used a copy (ctrl-c) for the dump. Do you want a dump for cut?
Yes please. add some more dumps (for cut and paste) to see whether it's always the same location.
Ok, I did it for copy, cut. Couldn't get it to happen for paste. Also hangs on revert file, so did it there too. Attaching below.
Created attachment 15250 [details] copy hang trace
Created attachment 15251 [details] cut hang trace
Created attachment 15252 [details] revert hang trace
Created attachment 15253 [details] pre hang trace A trace right after startup before any hangs have occurred
Created attachment 15254 [details] post hang trace A trace while not hung, but after performing all the other clipboard hang traces
Do you still see this using I200411010800 or newer?
Yes - problem is still present on 200411010800 Attaching a new stack trace
Created attachment 15565 [details] trace of hang on I20041101
We cannot reproduce this. There are two more things we can try: 1) add an .options file to Eclipse install location (where startup.jar is) with the following line: org.eclipse.jdt.core/debug/resolution=true and add -debug to your command line options. This will enable tracing. Attach the trace which is written when cut and one when copy takes long. 2) provide a step-by-step test case which starts from scratch
The trace doesn't seem to be taking effect - when .options was in my eclipse install directory, it wasn't mentioned when I ran with -debug. If I put it in the CWD when starting with -debug, it was mentioned, but nothing was output to standard out after the initial verbiage from startup. I also created an hprof dump which I'll attach - hopefully you'll be able to see where all the time was being spent.
Created attachment 15763 [details] hprof output Ran with "/opt/eclipse-3.1M3/eclipse -vmargs -Xmx512M -Xrunhprof:cpu=samples,file=hprof.txt,thread=y" then forced a hang 5 or 6 times to saturate cpu usage with correct stats.
Looks like reading the jar/zip files takes long. Jerome, did you hear about such a problem? Can you please take a quick look at the hprof output and see whether you see something suspicious? Please try to run with the .options file again. We really need that data. You could also use the following syntax: -debug <fullpath_to_options_file> i.e. 1. Edit <install_dir>/eclipse/plugins/org.eclipse.jdt.core_3.1.0 ==> set 2. start with: -debug <install_dir>/eclipse/plugins/org.eclipse.jdt.core_3.1.0/.options The console should then show (after some other initial debug output): Debug options: file:/<install_dir>/eclipse/plugins/org.eclipse.jdt.core_3.1.0/.options loaded
No I'm not seeing anything suspicious in the hprof file. Matthew, in addition to putting org.eclipse.jdt.core/debug/resolution=true, please add the following line: org.eclipse.jdt.core/debug/javamodel=true
Created attachment 15825 [details] Trace while doing a cut/copy Search for *** for point in the trace right before I executed a cut/copy which took a long time. Just to recap - this problem exhibits itself on a project with > 200 source paths and many jars in the classpath, if I reduce either of those two variables, the problem goes away. However, the problem did not exist in 3.0.1, so hopefully it can be fixed.
Jerome, can you take a look at the latest trace. You better know how to read your debug output. Thanks.
You're hitting the upper limit of the Java model cache. In an effort to reduce the memory used by Eclipse, this limit was set to 200 package fragment roots. Controlling this limit is reported as bug 72258. In the meantime, I would suggest to separate your source folders in different projects. This should improve things as only one project is looked at a time.
reopen to close as dup
As outlined in comment 30 this will be fixed once bug 72258 has been fixed. In my opinion bug 72258 is not an enhancement but a bug as we can see from this report. *** This bug has been marked as a duplicate of 72258 ***
