Bugzilla – Full Text Bug Listing
| Summary: | [clean up] Out of memory error while using Source > Cleanup | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Deepak Azad <deepakazad> |
| Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P5 | CC: | daniel_megert, markus.kell.r |
| Version: | 3.7 | Keywords: | performance |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | 150657 | ||
| Bug Blocks: | |||
|
Description
Deepak Azad
> I can try to increase the available
> memory, but there should not be a problem in the first place as the Clean up
> does not require more than one AST at a time.
How much memory do you give? Maybe it's failing because of a particular file. Can you check that?
(In reply to comment #1) > > I can try to increase the available > > memory, but there should not be a problem in the first place as the Clean up > > does not require more than one AST at a time. > How much memory do you give? Maybe it's failing because of a particular file. > Can you check that? Sure, I can take a look. But my first guess was that the exception had something to do with ASTBatchParser and the static initializer block in it. For performance reasons, clean ups create ASTs in batch. Unfortunately, we don't have any way to detect when we're running low on memory (bug 150657), so the best we can do is make an informed guess and hope for the best. The guesses in ASTBatchParser have been copied from MatchLocator, but it looks like we have to set the limits a bit lower (because we also build DOM ASTs that take more RAM). I've also run into this problem in the past with default VM args (256M) and huge projects. Deepak, can you please do some tests and adjust the numbers? E.g. use Runtime.getRuntime().gc() and then print out Runtime.getRuntime().freeMemory() in CleanUpASTRequestor#acceptAST(..) to see how much free memory is left. The ratio is computed with 64MB blocks, and the switch statement maxes out at maxMemory sizes > 256MB. I.e. nowadays, everybody runs with MAX_AT_ONCE, which usually runs out of memory with the default settings. As a short-term fix, I've released a readable implementation with more realisitc bounds: http://git.eclipse.org/c/jdt/eclipse.jdt.ui.git/commit/?id=094dcd3dced365d9ffe888c153b364fd20d93111 Manju, please do some experiments to find good bounds. Also test with projects that have many large files (create them yourself or e.g. copy some huge source files like StyledText or jdt.core's Parser). Also include some performance measurements (using "System.currentTimeMillis()") to find a working set size where adding more CUs to one batch doesn't improve performance any more (or only marginally). Use a real project like jdt.core or jdt.ui for this. The primary goal is to avoid OutOfMemory problems. Bigger batch sizes only make sense if they improve performance substantially, so if we find that adding more CUs to a batch doesn't win much time, then we better keep smaller batches. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |