I had three projects open. One of them - Spark - was very large. Upon closing spark there was NO difference in memory usage - as reported by os/x activity monitor. Note: all projects are opened within the same Intellij instance.
It is in fact using just over 4GB. And I only now have two projects open. Those two projects only take up 1.5GB if I shut down Intellij and start it up again.
So .. what to do to "encourage" Intellij to release the memory it is using? It is running very very slowly (can not keep up with my typing for example)
Update I just closed the larger of the two remaining projects. STILL no reduction in memory usage. The remaining project is a single python file. So Intellij should be using under 512Meg at this point!
Following up on #PeterGromov's answer it seems that is were difficult to obtain the memory back. In addition #KevinKrumwiede mentioned the XX:MaxHeapFreeRatio which appears to be an avenue.
Here are a couple of those ideas taken bit farther from Does GC release back memory to OS?
The HotSpot JVM does release memory back to the OS, but does so
reluctantly.
You can make it more aggressive by setting -XX:GCTimeRatio=19
-XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30 which will allow it to spend more CPU time on collecting and constrain the amount of
allocated-but-unused heap memory after a GC cycle.
Additionally with Java 9 -XX:-ShrinkHeapInSteps option can be be used
to apply the shrinking caused by the previous two options more
aggressively. Relevant OpenJDK bug.
Do note that shrinking ability and behavior depends on the chosen
garbage collector. For example G1 only gained the ability to yield
back unused chunks in the middle of the heap with jdk8u20.
So if heap shrinking is needed it should be tested for a particular
JVM version and GC configuration.
and from How to free memory in Java?
To extend upon the answer and comment by Yiannis Xanthopoulos and Hot
Licks (sorry, I cannot comment yet!), you can set VM options like this
example:
-XX:+UseG1GC -XX:MinHeapFreeRatio=15 -XX:MaxHeapFreeRatio=30 In my jdk 7 this will then release unused VM memory if more than 30% of the heap
becomes free after GC when the VM is idle. You will probably need to
tune these parameters.
While I didn't see it emphasized in the link below, note that some
garbage collectors may not obey these parameters and by default java
may pick one of these for you, should you happen to have more than one
core (hence the UseG1GC argument above).
I am going to add the -XX:MaxHeapFreeRatio to IJ and report back if it were to help.
Our application presently only runs on Java7 so the first approach above is not yet viable - but there is hope since our app is moving to jdk8 soon.
https://www.jetbrains.com/help/idea/status-bar.html
I used this:
Shows the current heap level and memory usage. Visibility of this section in the Status bar is defined by the Show memory indicator check box in the Appearance page of the Settings/Preferences dialog. It is not shown by default.
Click the memory indicator to run the garbage collector.
The underlying Java virtual machine supports only growing of its heap. So even if after closing all projects the IDE doesn't need all of it, it's still allocated and counted as used in the OS.
Related
My IntelliJ goes unbearably slow, so I was fiddling with memory settings. If you select Help -> Change Memory Settings, you can set the max heap size for IntelliJ. But even after restarting, then running Mac's Activity Monitor, I see it using 5.5GB even though I set the heap to 4092MB.
It's using 1.5GB more than allocated for heap. That's a lot of memory for permgen + stack, don't you think? Or, could it be that this memory setting actually doesn't have any effect on the program?
It's the virtual memory you see, it may also include memory mapped files and many other things occupied by the JVM internals, plus the native libraries for a dozen of Apple frameworks loaded into the process. There is nothing to worry about unless you get OOM or IDE becomes slow.
If it happens, refer to the KB documents and report the issues to YouTrack with the CPU/Memory snapshots.
I was trying to debug the memory growth in generation analysis and was frustrated (Lots of objects that was the result of call toCGGlyphBitmapCreate was not being released) . Then, I ran the program on simulator and captured many generation snapshots and then I did a simulate memory warning. Almost every generation cleared to zero ( a few had a few bytes here and there). Does that mean my code is fine and I should not worry about it? How can I prevent the growth so that it wont have to wait until a simulate memory warning event to clear the growth? (By the way, all these growth was caused by system libraries)
If the memory is getting released upon memory warning, then you're probably OK. The OS will cache all sorts of stuff (that it will free/reuse as it sees fit) that you don't generally have to be concerned about.
Still, I would run the code through the static analyzer (press shift+command+B in Xcode or select "Analyze" on the Xcode "Product" menu) just to be safe.
I have been using IntelliJ IDEA 12 for developing a Java Applications. I have the best experience for an IDE. It was working fine until recently. It started to show the heap size memory issue recommending to increase the Xmx and ask me to ignore or shutdown. The behaviour is weird as the IDE starts at 300 MB then it starts to take more memory until it reaches 750+ MB that's when it shows the problem.
I switched back to eclipse and the memory foot print is stable at 300 MB and doesn't increase by time like IntelliJ
Is IntelliJ doing some background process related to my code causing this increase? or is it a memory leakage problem with the IDE?
I've used IDEA for 10 years (and used IDEA 12 for a year before switching to IDEA 13 EAP builds) and have never had a memory issue. And I do not see any consistent mention of memory issues in the IDEA forums.
That said, a memory leak was just fixed (as in released today) in the IDEA 13 EAP. The VcsLogGraphTable class had a leak. The ticket does not give any indication if the leak was/is present in IDEA 12. Based on the name of the class, it should only come into play for Git or Hg graphs (but Hg graphs were added in 13). Based on my experience with how they do tickets, I interpret this as an IDEA 13 issue.
First, make sure you are using the latest version 12.1.6.
Often times memory issues are a result of a poorly written third party plug-in. You can try to disable any third party plug-ins and see if the issue is resolved.
The other thing you can do is follow the instructions in the document How to report IntelliJ IDEA performance problems and take CPU snapshots and report the issue to JetBrains. That way they can confirm a leak in IDEA 12, or tell you what plug-in is the culprit.
What does "Memory" usage chart/graph exactly represents in XCode 5 Debug navigator window?
I have an iOS app project with ARC disabled and no-storyboard/xib (i.e. old style). All memory management done manually using retain/release/autorelease.
When I debug the project in XCode 5, the memory pie-chart / graph show gradually increasing memory usage as the app runs, exceeds 1 GB memory footprints within half hour.
Roughly, it keeps increasing by 0.1 to 0.3 MB per 2 to 3 second with very rare memory dips/decrease (of magnitude < 0.1 MB per 30 seconds).
Is this a concern (memory leak) with respect to memory management? I did memory analysis (using Allocations/Memory Leak through Instruments on XCode 4.6) but didn't find any leaks.
Found answer myself. Unfortunately I had NSZombieEnabled (Zombie object) for debug mode - see below - (menu Product > Scheme > Edit Scheme)
Typically NSZombieEnabled tool keeps even the released objects in memory to help developer find over released objects. Refer this link - What is NSZombie?
After I unchecked "Enable Zombie Objects" option, the memory usage stabilized to about 10 mb (not always increasing) even after half hour app usage - see below -
BOTTOM LINE - Ensure to clear "Enable Zombie Objects" when you want to analyze memory usage.
It simply measures the memory your app uses. So if it is increasing it must be a memory leak.
When using the leak analysis tools, I would use it as a guideline. It may help you find leaks but with all automated tools it may not find it all. As certain pieces of code (Especially the more dynamic pieces) may be hard to predict what they do memory wise for an automated tool.
I am seeing an issue where memory (heap) grows indefinitely on heavy processing but when running the exact same binary without Xcode; memory usage is fine. Remember to test outside of Xcode -- no idea what the cause is. NSZombies and all other debug options are off.
I have a WebSphere Portal application running four instances on a single box and after about 7 days of runtime there is only 130-150mb of address space free in native memory (using PMAP). Somewhere in another 7-10 days the figure drops well below 100mb (which we deem dangerous and we start to recycle the JVM). If we don't do the recycle, the JVM will eventually crash with a SIGSEGV signal.
We've done some initial investigation into class counts and the size of JIT code. Class counts grow, but slowly from 50k onwards...about a couple hundred per day. JITC sizes get to about 210 MB after 7 days and grow about 1 MB per day after that so. In our previous experience we don't find these to be sinister values.
What we need to to be able to break down what is in the native heap, whether it is threads (all thread counts appear normal and we have fixed thread pools), String pools, constant pools, bytecode, or whatever else.
One lead we are trying now is reducing the reflection threshold to 0 (shutting off the bytecode accessors for reflectively created classes). This app uses a lot of pointcutting and a lot of reflection, so we're hoping there's a good chance this helps.
Any advice is welcome.
Might be a bit of back-and-forth, but have you GC logged and ensured it's not growing Java heap over time? Looked at your perm space? The SIGSEGV is an interesting one though, I'd expect a more JVM-ish crash for any in-Java mem issues.
After lengthy investigation, this ended up being a WebSphere bug: PK72252: CALLS TO CLASSLOADER.GETRESOURCEASSTREAM ARE SLOW. Fixed in 6.0.2.33.