Possible issue with a large quantity of class files

[java-decompiler]

Possible issue with a large quantity of class files

[imcraymond]

I just tried 1.4. My "guess" is that it is a memory issue. The directory tree fully displays, but as I go down the list to open a class file, some open others do not. There doesn't appear to be a pattern, so I'm thinking it has to do with the sequence the classes are loaded in. Assuming they don't load alphabetically...

I am using the "Windows" exe version.

[emmanue1]

Hi Craig. The C++ version suffers from the limitation of Win32 GDI : once all the GDI handles are consumed, some bugs appear on the GUI. For the Java/Groovy version, the graphic resources saturation is less clear for me. To validate your hypothesis, you can try to increase Xmx:

java -Xmx1024m -jar jd-gui-x.y.z.jar

Another hypothesis may be that the background indexing mechanism, consumes too much resource (CPU & memory) and destabilizes the JVM.

[imcraymond]

With a 32 bit java at 768m I see the following:
Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
at org.codehaus.groovy.runtime.callsite.BooleanReturningMethodInvoker.invoke(BooleanReturningMethodInvoker.java:53)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.grep(DefaultGroovyMethods.java:2444)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.grep(DefaultGroovyMethods.java:2471)
at org.codehaus.groovy.runtime.dgm$305.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:271)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callSafe(AbstractCallSite.java:82)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:335)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:369)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:207)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:338)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:369)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
...

Using a 64 bit java with Xmx = 2048m I get the following:
Exception in thread "AWT-EventQueue-0" java.lang.StackOverflowError
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.codehaus.groovy.runtime.callsite.BooleanReturningMethodInvoker.invoke(BooleanReturningMethodInvoker.java:53)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.grep(DefaultGroovyMethods.java:2444)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.grep(DefaultGroovyMethods.java:2471)
at org.codehaus.groovy.runtime.dgm$305.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:271)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:53)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:333)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:369)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:207)
at org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:56)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:185)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:338)
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:369)
at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
...

Both hinge at the same point PogoMetaMethodSite.java:207. I've played with a few other settings for Xmx (all on 64 bit) and it seems to bounce around between the two above stacktraces. Interestingly, my max memory usage on the box ends up around 6.4 gig using both 4096m and 5120m.

[emmanue1]

OK. I see on both stacktraces:

at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:333)
...
at org.jd.gui.view.component.TypePage.searchTypeHavingMember(TypePage.groovy:335)

This method executes a recursive search on indexes to enable or disable hyperlinks on the page. I can add a try-catch to prevent this stack overflow.