The Artima Developer Community
Sponsored Link

Java Buzz Forum
A little practical GC tuning – on Eclipse

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Mathias Bogaert

Posts: 618
Nickname: pathos
Registered: Aug, 2003

Mathias Bogaert is a senior software architect at Intrasoft mainly doing projects for the EC.
A little practical GC tuning – on Eclipse Posted: Feb 4, 2013 12:31 AM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Mathias Bogaert.
Original Post: A little practical GC tuning – on Eclipse
Feed Title: Scuttlebutt
Feed URL:
Feed Description: tech gossip by mathias
Latest Java Buzz Posts
Latest Java Buzz Posts by Mathias Bogaert
Latest Posts From Scuttlebutt

JVM GC tuning is a vast field that books have been written about. Mostly, we’re happy to accept whatever defaults the JVM figures out, at most cranking up heap and permGen size when we’re out of memory (again). I’ve found that with the ScalaIDE plugin installed, Eclipse was so memory-heavy and often still sluggish that I’ve spent some time tuning. Why? Besides the fact that a glorified Texteditor with a compiler attached needs gigabytes of memory, the darned thing was still slow, often becoming unresponsive for some seconds. This sucks. The defaults The JVM settings live in Eclipse’s ini file, which you get to visit fairly quickly to crank up the 512M heap to 1G as recommended by the Scala plugin, ending up with this: 123-XX:MaxPermSize=256m -Xms40m -Xmx1g That didn’t work so well… After a couple of minutes, the IDE locks up. A quick look at the JVM memory, using JVisualVM (part of the JDK), tells us why: That didn’t take long. Ok, so 1GB heap doesn’t get us very far. But hey, memory is cheap, so let’s give it 3GB and also up the perm a little, since that’s on an upwards curve as well. Memory fatpants 123-XX:MaxPermSize=320m -Xms40m -Xmx3g So, let’s do this again. The project I’m using has 12 modules by now, of which some depend on others, so there’s a fair bit of compilation that triggers compilation going on. Now I’m not doing anything special here, just editing source, using the autocompleter, etc. The IDE is still slow to interact with, having frequent pauses and generally feeling sluggish to the point that things you type take a bit of time to actually appear, just as if I was actually remote-controlling another machine. Now it could be that it’s simply a crappy application, but let’s take another look at the JVM and see what the “memory fatpants” have done for us: Nearly all the memory went to the old generation, and eden is just getting hammered with minor GCs. From the actual usage of the old gen we can see that there aren’t that many long-lived objects around, it’s just young overflowing. Old gen full GCs are way more expensive than young gen GCs, so we usually don’t want that to happen. A quick look at JConsole (also part of the JDK) tells us that we’re actually running the CMS (ConcurrentMarkSweep) GC: This is due to some odd things Apple has done the the JVM: Mac OSX Java HotSpot VM is client by default and uses CMS. So next step of action: Increase new ratio, switch to server JVM That’s what I thought I had all along… 12345-server -XX:MaxPermSize=320m -XX:+UseParallelGC -Xmx3g -Xmn2g I’m now enforcing a large new generation and switched the garbage collector from CMS (which would constantly churn on old) to parallel GC. Time to test again. That’s better. We’ve gone down from 1000+ minor GCs to 16, with the time spent on minor GC reduced by order of magnitude. The old gen GCs take [...]

Read: A little practical GC tuning – on Eclipse

Topic: JVM Performance: Adaptive Optimization and Control for Applications Previous Topic   Next Topic Topic: Improving Agile Estimation via Triangulation

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use