Summary: | [index] Indexer runs out of memory | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Kent Beck <kentb> |
Component: | Core | Assignee: | Frederic Fusier <frederic_fusier> |
Status: | VERIFIED NOT_ECLIPSE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | daniel_megert, irbull, Olivier_Thomann |
Version: | 3.5 | ||
Target Milestone: | 3.5 M7 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=474323 https://bugs.eclipse.org/bugs/show_bug.cgi?id=213702 |
||
Whiteboard: |
Description
Kent Beck
2009-03-12 11:08:17 EDT
Moving to JDT/Core What is JUnit Max? What was your -Xmx value when you run it? (In reply to comment #2) > What is JUnit Max? What was your -Xmx value when you run it? JUnit Max is a plugin that runs a project's tests riskiest-first when you save a Java file in that project and then reports the results as markers. Max is being activated at startup but it doesn't do anything significant that I could see (obviously not or the indexer wouldn't choke). The indexer runs out of memory before any file has been edited, so Max isn't running when the problem occurs. So, I guess you use the default eclipse default heap size (256M)? (In reply to comment #4) > So, I guess you use the default eclipse default heap size (256M)? Sorry about that. Correct, default heap size. I am getting this with I20090313-0100 simply by starting a run-time workbench (I get it in the run-time workbench). All I have installed in mylyn and a custom cheat sheet project. I'm using the Eclipse defaults. (In reply to comment #6) > I am getting this with I20090313-0100 simply by starting a run-time workbench > (I get it in the run-time workbench). All I have installed in mylyn and a > custom cheat sheet project. > > I'm using the Eclipse defaults. > This one is a duplicate of bug 166223... You just need to set the heap size at least to 256M (default while starting a work time workbench is the default VM, i.e. 64M...)
> This one is a duplicate of bug 166223... You just need to set the heap size at
> least to 256M (default while starting a work time workbench is the default VM,
> i.e. 64M...)
>
Thanks for pointing me at this bug Fredric. I wonder if more is going on here though. In my target workspace I only have simple mail app, and I've not added anything to my java search path. Do you think the indexer would fail with this setup with 65M of heap space?
(In reply to comment #8) > Thanks for pointing me at this bug Fredric. I wonder if more is going on here > though. In my target workspace I only have simple mail app, and I've not added > anything to my java search path. Do you think the indexer would fail with this > setup with 65M of heap space? > I guess your app at least uses a JDK 6.0, doesn't it? This would imply the indexing of approx. 37,000 class files, hence may explain that the max memory was reached (note that starting with a heap of 64M, does not mean that the indexing can use all of it...) Could you make a try just with 128M and see if it works (I guess it should...)? (In reply to comment #9) > I guess your app at least uses a JDK 6.0, doesn't it? This would imply the > indexing of approx. 37,000 class files, hence may explain that the max memory > was reached (note that starting with a heap of 64M, does not mean that the > indexing can use all of it...) Could you make a try just with 128M and see if > it works (I guess it should...)? > Good call on the Java 1.6 thing. However, I set: -Xms40m -Xmx256m and I'm still getting the heap space error. I'm not sure that PDE is actually using these args (when I look at the configuration in the about dialog the heap space arguments are not there). I opened bug 268711 for the PDE issue. Thanks for your help Frederic. (In reply to comment #11) > I opened bug 268711 for the PDE issue. Thanks for your help Frederic. > You're welcome, but I wonder whether there's a real issue with PDE or not. I often change -Xmx values in my launch config and it's well taken into account... Note also that I did make a test in a brand new workspace with an empty project using JDK 6.0 and I was able to index all the classes with 64M. Does your mail app contain a lot of source files or have a lot of plugins/jars dependencies? Was there a compilation running while the OOME occurred? > You're welcome, but I wonder whether there's a real issue with PDE or not. I > often change -Xmx values in my launch config and it's well taken into > account... Yep, my misunderstanding of how the launcher arguments are applied. > > Note also that I did make a test in a brand new workspace with an empty project > using JDK 6.0 and I was able to index all the classes with 64M. Does your mail > app contain a lot of source files or have a lot of plugins/jars dependencies? > Was there a compilation running while the OOME occurred? > The mail app was the simple one that PDE generates (new plug-in project > create an RCP app, select "Simple RCP Mail" from the list of templates. There were no other custom settings, so if a compilation was occurring, it would have just been the automatic build. (In reply to comment #13) > > > > Note also that I did make a test in a brand new workspace with an empty project > > using JDK 6.0 and I was able to index all the classes with 64M. Does your mail > > app contain a lot of source files or have a lot of plugins/jars dependencies? > > Was there a compilation running while the OOME occurred? > > > The mail app was the simple one that PDE generates (new plug-in project > > create an RCP app, select "Simple RCP Mail" from the list of templates. > > There were no other custom settings, so if a compilation was occurring, it > would have just been the automatic build. > I did the same test and got only a max of 105M for the heap size after the indexing finished!? So, I retry with a -Xmx128M and never got any OOME with the same test case. Note that obviosuly starting with less memory (e.g. 64M) makes the indexer crashing... As with a "pure" eclipse install, we're definitely far from the described OOME in both cases (Kent and you), my assumption is that the additional plug-ins (JUnitMax, MyLyn ) could be responsible of an extra memory consumption which may not leave enough room for the indexer to finish its work properly. So, currently close this bug as NOT_ECLIPSE... FYI, see bug 215376 to track work around the OOME raised by the indexer when there's definitely not enough room to finish the jar indexing... Verified for 3.5M7. |