Bugzilla – Full Text Bug Listing
| Summary: | Eclipse uses much more memory than Xmx is configured | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Slava Go <slavago> |
| Component: | SWT | Assignee: | Till Brychcy <register.eclipse> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | alkotobnour, dbo, enegy, loskutov, register.eclipse, rolf.theunissen, sravankumarl |
| Version: | 4.12 | ||
| Target Milestone: | 4.13 M3 | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=489451 https://bugs.eclipse.org/bugs/show_bug.cgi?id=508491 https://git.eclipse.org/r/147241 https://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=53f08313f43802adc93682794f30a3fdd5a11954 |
||
| Whiteboard: | |||
|
Description
Slava Go
Like with any Java program, Xmx does not set the maximum total used memory for the JVM [1]. Do you have any particular issue with the amount of memory used not related to normal JVM behavior? [1] https://stackoverflow.com/questions/53451103/java-using-much-more-memory-than-heap-size-or-size-correctly-docker-memory-limi Well, main issue that I think 2 latest updates (including 4.12) Eclipse used about 5GB RAM even if there's no any program in the debug. It's was not the behaviour in the past. And even if Xmx not set maximum, fr JVM, anyway 2.5 times more usage of RAM from specified in Xmx is a lot. Thanks The first suspect in this case would be the JVM itself. Which version of the JVM do you use, and is it the same as the one you used for 2 releases back? In general, much memory usage is only a problem when you run out of free available memory. Keeping memory empty can be considered as a waste of resources. Using much memory can improve your system performance. How memory is used by the JVM and by the OS is surely not as intuitive as it seems at first sight. That said, I do not claim that Eclipse is not wasting memory. You could use 'native memory tracking' [1] to see how the memory is consumed. [1] https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html I'm running on JDK 8 Update 152. Running on it few years already on different Eclipse versions. The high memory usage is problematic for me ,as in many cases in parallel I run windows VM on the same computer, so I noticed high memory pressure (this is how Mac describes it :)). So, it's a problem. Thanks I cannot reproduce this memory jump on my Windows PC. Somebody should provide more details about how the memory is consumed, otherwise this issue cannot be further analyzed. There's definitely memory leak, my Eclipse now using about 9GB of RAM, checked this with my colleagues (all on Mac) , all see same behaviour, Eclipse memory usage is climbing, in 3 days raised from 1.8GB at start to 8.5GB. (In reply to Slava Go from comment #6) > There's definitely memory leak, my Eclipse now using about 9GB of RAM, > checked this with my colleagues (all on Mac) , all see same behaviour, > Eclipse memory usage is climbing, in 3 days raised from 1.8GB at start to > 8.5GB. Please create a memory dump with jmap and check what are the dominating objects in the dump with any profiler tool. Also attach the output of "jmap -heap" and "jmap -histo" here. (In reply to Andrey Loskutov from comment #7) > Please create a memory dump with jmap and check what are the dominating > objects in the dump with any profiler tool. Also attach the output of "jmap > -heap" and "jmap -histo" here. The memory consumption by java objects is limited by -Xmx etc., so this cannot help. Can you try the "leaks" command line tool? If I run it, I actually see some leaks, esp. some related to NSBitmapImageRep: [...] 8 (832 bytes) ROOT LEAK: <NSBitmapImageRep 0x7ff853709ec0> [80] 5 (672 bytes) _dataObj --> <CGImage 0x7ff8645613c0> [288] 3 (336 bytes) <CGDataProvider 0x7ff897608760> [272] 2 (64 bytes) 0x7ff8a0035c40 [32] 1 (32 bytes) <NSCustomReleaseData 0x7ff8537e3520> [32] 1 (48 bytes) <RIPData 0x7ff8976a6820> [48] 2 (80 bytes) _properties --> <NSMutableDictionary 0x7ff8976fac30> [32] 1 (48 bytes) <NSMutableDictionary (Storage) 0x7ff8931bf120> [48] [...] Maybe they add up to multiple GB over time? I've temparily introduced a subclass SWTBitMapImageRep and selectively used it instead of plain NSBitmapImageRep to narrow down where the leaked reps are created and found (so far) the following results: most leaked are created from org.eclipse.swt.internal.graphics.ImageUtil.createImageRep(Image, NSSize) (added by Bug 489451) some others from org.eclipse.swt.graphics.Image.initAlpha_200(NSBitmapImageRep) (added by Bug 508491) (In reply to Till Brychcy from comment #8) Ran leaks and have pretty big report file. My Eclipse increased memory usage from 1.5GB to 2.5GB for 12 hours. This is part of the report : 7 (784 bytes) ROOT LEAK: <NSBitmapImageRep 0x600001519a40> [80] 4 (624 bytes) _dataObj --> <CGImage 0x7fa2c7bd3a50> [288] 3 (336 bytes) <CGDataProvider 0x7fa2c7b94070> [272] 2 (64 bytes) 0x60000b765920 [32] 1 (32 bytes) <NSCustomReleaseData 0x60000b766e00> [32] 2 (80 bytes) _properties --> <NSMutableDictionary 0x60000b767dc0> [32] item count: 1 1 (48 bytes) <NSMutableDictionary (Storage) 0x6000020697d0> [48] 7 (784 bytes) ROOT LEAK: <NSBitmapImageRep 0x60000154b660> [80] 4 (624 bytes) _dataObj --> <CGImage 0x7fa2c7dcd7d0> [288] 3 (336 bytes) <CGDataProvider 0x7fa2c7dcf980> [272] 2 (64 bytes) 0x60000b768020 [32] 1 (32 bytes) <NSCustomReleaseData 0x60000b714ae0> [32] 2 (80 bytes) _properties --> <NSMutableDictionary 0x60000b712e60> [32] item count: 1 1 (48 bytes) <NSMutableDictionary (Storage) 0x60000201bea0> [48] 7 (784 bytes) ROOT LEAK: <NSBitmapImageRep 0x600001572670> [80] 4 (624 bytes) _dataObj --> <CGImage 0x7fa2c7dd1350> [288] 3 (336 bytes) <CGDataProvider 0x7fa2c7d94de0> [272] 2 (64 bytes) 0x60000b762d40 [32] 1 (32 bytes) <NSCustomReleaseData 0x60000b717f60> [32] 2 (80 bytes) _properties --> <NSMutableDictionary 0x60000b717d20> [32] item count: 1 1 (48 bytes) <NSMutableDictionary (Storage) 0x60000206cd50> [48] 7 (784 bytes) ROOT LEAK: <NSBitmapImageRep 0x600001573430> [80] 4 (624 bytes) _dataObj --> <CGImage 0x7fa2c7dca5e0> [288] 3 (336 bytes) <CGDataProvider 0x7fa2c7dca4d0> [272] 2 (64 bytes) 0x60000b712ca0 [32] 1 (32 bytes) <NSCustomReleaseData 0x60000b707e40> [32] 2 (80 bytes) _properties --> <NSMutableDictionary 0x60000b709080> [32] item count: 1 1 (48 bytes) <NSMutableDictionary (Storage) 0x600002060f30> [48] 5 (704 bytes) ROOT LEAK: <NSBitmapImageRep 0x600001519c70> [80] 4 (624 bytes) _dataObj --> <CGImage 0x7fa2c7888e40> [288] 3 (336 bytes) <CGDataProvider 0x7fa2c7a8b430> [272] 2 (64 bytes) 0x60000b762840 [32] 1 (32 bytes) <NSCustomReleaseData 0x60000b765b80> [32] Thanks New Gerrit change created: https://git.eclipse.org/r/147241 Gerrit change https://git.eclipse.org/r/147241 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=53f08313f43802adc93682794f30a3fdd5a11954 (In reply to Eclipse Genie from comment #12) > Gerrit change https://git.eclipse.org/r/147241 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=53f08313f43802adc93682794f30a3fdd5a11954 Thanks Till for identifying the problem and fixing it. @Slava, the latest integration builds downloadable from https://download.eclipse.org/eclipse/downloads/ contain the fix. (In reply to Till Brychcy from comment #14) > @Slava, the latest integration builds downloadable from > https://download.eclipse.org/eclipse/downloads/ contain the fix. Thanks, is there any chance that this will be released as some update to 4.12 ? (In reply to Slava Go from comment #15) > (In reply to Till Brychcy from comment #14) > > @Slava, the latest integration builds downloadable from > > https://download.eclipse.org/eclipse/downloads/ contain the fix. > > Thanks, is there any chance that this will be released as some update to > 4.12 ? I can only second this. If there is any chance, please consider a fix on 4.12, since this problem urges me to restart Eclipse every few hours.. In addition the fix commit reads straight forward, so supposedly doesn't regress anything. IMHO users shouldn't wait for another month. *** Bug 551145 has been marked as a duplicate of this bug. *** *** Bug 550142 has been marked as a duplicate of this bug. *** |