Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: 3.2.0.v_671 (version info on JDT jar file) Main issue of this case is OutOfMemory issue. We identified that application classloader i.e. compoundClassLoader is not freeing up even after application has been stopped. The reason we believe is thread named "java indexing" owned by Eclipse JDT component is referencing this compound classloader from it's threadLocal. And as we know threadLocal object has native reference and never been destroyed The belief is that if compound classloader from Thread Local is not referenced the OOM will not occur Reproducible: Always Steps to Reproduce: Our defect scenario can be reproduced as follows: - deploy a web application with JSPs to WAS - visit the JSPs via your browser. This will trigger JSP compilation. We suspect that the compilation uses some JDT features which then spawn the indexer thread referencing the web applications classloader
Satyam, please investigate.
Created attachment 153348 [details] Image of Memory Analyzer result
The attached image seems to indicate that the compound class loader is the parent of the Indexing thread's context class loader. Thus the context class loader is probably holding up some memory, but as there will be only one index thread, it is unlikely that the memory should grow indefinitely for each application start and stop. I couldn't try out much with WAS server yet -- should do that and update my comments.
Created attachment 153477 [details] Probable code changes that could help (3.2 Maintenance branch) This is not a proper patch that could be applied as yet. However, I just want to propose the probable fix that could help. In this patch, the thread context class loader for the internal threads is being set to the class's class loader. By doing this the Indexing thread should not reference the compound class loader. I will generate a plugin based on this patch, which could be tried over.
It would be good to have a test case for this. Once scenario you could try to build is having a huge workspace, delete the index, start and wait until the indexer starts. Then exit. I would expect that the indexer aborts immediately and all goes well. Hence I can not quite understand why we would run into OOME due to the Java indexer.
(In reply to comment #5) > Hence I can not quite understand why we would run into OOME > due to the Java indexer. The "Java Indexing" thread is having a reference to the context class loader, because of which that class loader and those classes are not getting garbage collected. WAS 6.2 seems to be using only the compiler part of the JDT Core and not really doing any indexing! It is just that the indexing thread gets created at the JDT Core plugin activation time, but I dont think it is really getting used!
>The "Java Indexing" thread is having a reference to the context class loader, >because of which that class loader and those classes are not getting garbage >collected. Sure, but the indexer gets stopped/disposed on shutdown. Why should this cause an OOME? Please explain.
(In reply to comment #7) > >The "Java Indexing" thread is having a reference to the context class loader, > >because of which that class loader and those classes are not getting garbage > >collected. > Sure, but the indexer gets stopped/disposed on shutdown. Why should this cause > an OOME? Please explain. The JDT plugin does not seem to be getting stopped. It is not getting loaded on the application context. All the applications loaded on WAS does seem to be using the same JDT plugin. Hence, when one application gets stopped it doesn't stop the JDT plugin and hence the indexer is still running.
OK, so is that the scenario: the server continues to run after the app is closed and JDT Core stays in memory and then *something* causes an OOME? If that's the case then I suspect that your fix will not do the trick because JDT Core will not know that the app is closed and will therefore keep holding on to the types that are cached in its model.
I don't think the model is being used at all. It looks like the compiler is the only one that is being used by the server. Well, I have to say -- I am not sure! Yes, you are right there could be some significant JDT memory that is being still hold and as the server and the Eclipse version that is being used are pretty old, I am being conservative and trying to address only the problem that is stated. BTW, I have given the plugin patch to the customer and waiting for the feedback - I was having problem accessing bugzilla and hence just send it directly.
>BTW, I have given the plugin patch to the customer and waiting for the feedback >- I was having problem accessing bugzilla and hence just send it directly. Yes, I saw it. Let's wait for their feedback before spending more time on this.
Created attachment 155475 [details] Proposed patch for 3.2 maintenance stream
Created attachment 155478 [details] Proposed patch for 3.5.2
Created attachment 155479 [details] Proposed patch for 3.6
Patch looks good.
Released for 3.6M5.
Released for 3.5.2. Added regression test: org.eclipse.jdt.core.tests.model.JavaSearchBugsTests#testBug296343
Bug cloned for 3.4.2+ release (bug 299051) Bug cloned for 3.3.2+ release (bug 299053) Bug cloned for 3.2.2+ release (bug 299054)
Verified for 3.5.2 RC2 by code inspection.
Verified for 3.8M2 by code inspection.
