Community
Participate
Working Groups
Created attachment 124363 [details] Full stack dump java version "1.6.0_10" Java(TM) SE Runtime Environment (build 1.6.0_10-b33) Java HotSpot(TM) Client VM (build 11.0-b15, mixed mode, sharing While the autocomplete is open and typing "gl" to get a list and corresponding functions' Javadoc visible, the GUI freezes after the first g-letter has been typed. I couldn't test this with other libraries as I have not encountered one with as many functions beginning with the same name. For the test project I have added external jar "jogl.jar" and it's javadoc (tried with the same Javadoc in archive, not unzipped but problem presists. Also I have tried to make do without the Javadoc and although the freeze duration shortens, it still exists): - JOGL jar's and binaries for Win & Linux: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1/jogl-1.1.1-windows-i586.zip - JOGL documentation: http://download.java.net/media/jogl/builds/archive/jsr-231-1.1.1/jogl-1.1.1-docs.zip The code I used was simply this: GL test; // invoke code completion on the next line and start typing gl, it'll freeze test. / End of code Attached: - Full thread dump, obtained with Eclipse debugging Eclipse and sending Ctrl+Break to debugged process. - Eclipse configuration details
Created attachment 124364 [details] Eclipse configuration details
What do you mean with freeze? Did it never come back? The stack dump indicates that it isn't a deadlock. Which build? Is it reproducible?
What you can do is to attach the source to the library or to reduce the timeout when for fetching parameter names on the Java > Editor > Content Asssist > Advanced preference page. Moving to Java core to investigate the performance problem: at java.io.WinNTFileSystem.getLastModifiedTime(Native Method) at java.io.File.lastModified(Unknown Source) at java.util.zip.ZipFile.<init>(Unknown Source) at java.util.zip.ZipFile.<init>(Unknown Source) at org.eclipse.jdt.internal.core.JavaModelManager.getZipFile(JavaModelManager.java:2203) at org.eclipse.jdt.internal.core.SourceMapper.findSource(SourceMapper.java:912) at org.eclipse.jdt.internal.core.SourceMapper.getSourceForRootPath(SourceMapper.java:891) at org.eclipse.jdt.internal.core.SourceMapper.findSource(SourceMapper.java:855) at org.eclipse.jdt.internal.core.SourceMapper.findSource(SourceMapper.java:834) at org.eclipse.jdt.internal.core.BinaryMethod.getParameterNames(BinaryMethod.java:165) at org.eclipse.jdt.internal.codeassist.InternalCompletionProposal.findMethodParameterNames(InternalCompletionProposal.java:120) at org.eclipse.jdt.core.CompletionProposal.findParameterNames(CompletionProposal.java:1950)
Darn, I knew I forgot something. The freeze is not permanent, it's around 25 seconds. Build is eclipse.buildId = M20080911-1700, in second attachment. It is reproducible. Version is 3.4.1 (I downloaded the Java edition, I has used the Classic edition but the problem presists) to try TPTL I found another Java-OpenGL library, LWJGL, it has Javadoc also and contains (I would guess) all of the same OpenGL-function calls, but that Javadoc doesn't make these freezes So could it be something like Javadoc parsing problem, the link in my first post (JOGL documentation) is the Javadoc that makes the ~20second freezes.
Did you try the settings I suggested?
Changing the timeout from default 50 to 10 to 500 did not affect the freezing time in any noticeable way, it's still around 25 seconds, give or take 2seconds.
AAand to show my great reading skills, I attached the sources but they dont seem to contain Javadoc to the gl* JNI methods, so only little slowdown was detected.
>Changing the timeout from default 50 to 10 to 500 Set it to 1 or 0 for a test.
Changing it to 0 and restarting Eclipse (I think this did it) made it very fast again. Changing it to 1 or 100 and restarting made it take around 25 seconds, no noticeable difference in time between 1 and 100. Triple-checked. Yes. 0 is fast and 1 and 100 are extremely slow. Thank you. What's the catch here ? Badly formatted Javadoc? (Shouldn't be able to freeze like that, should it?) Or a real bug somewhere ?
No. 0 means don't extract the parameter names from Javadoc. AFAIK JDT Core caches a few recently opened Javadoc pages. Either we have a scenario where the cache is flushed or we have a performance bug when extracting the parameter names.
My bad. gl.glB.. autoassist is now fast but when i try to get autoassist for gl.glD.., it'll freeze for another 25 seconds and after that if I try to autoassist gl.glB..., it freezes for 25 seconds until I restart eclipse again.
The problem is caused by the large number of members in GL. Extraction of parameter names should be improved. A workaround is to type more characters before doing code assist (at least 3) Type 'glA' and then call code assist. *** This bug has been marked as a duplicate of bug 237241 ***
