It Is Nice To See JVM Shrink Its Heap…
Every Flex developer and their mother knows that the Flex compiler uses a lot of memory to build applications! That’s not good… Fortunately, Adobe continues to work diligently to reduce the compiler’s memory usage. That being said, we still have to deal with what we currently have. We all know that once you get JVM to grow the heap to build your applications, it is tricky to make it give the memory back to the operating system. Take a look at the following example, I use Flash Builder to build the Flex framework projects that are setup in the Flex open source branch.
Flash Builder, at peak usage, uses just above 460 MB of memory to run a full build. After a forced garbage collection, the memory reading stays there… pretty much unchanged.
Of course, using the Windows Task Manager is hardly scientific. So I switch to Java Visual VM.
The orange line shows that the JVM heap does not shrink at all after a forced garbage collection. That kinda corroborates with the reading in the Windows Task Manager. There are many reasons why JVM does not shrink the heap. One obvious reason is that the used heap (blue line) stays relatively high there.
Now, I reconfigure Flash Builder to use HFCD to build the same Flex framework projects. The Windows Task Manager shows that the HFCD memory usage, at its peak, uses about 395MB of memory. But the memory usage of HFCD plunges to 80MB after running a full build. HFCD gives a huge chunk of memory back to the operating system!!
The Java Visual VM again, corroborates with the reading in the Windows Task Manager. Note that the orange line falls off a cliff after a full build. The JVM heap shrinks to a level well under 100MB!
If you are in the “memory-is-cheap” camp, you probably will not care. But it’s a big deal if you want to run some other applications during the day and when Flash Builder is holding onto a large chunk of system memory.
I will talk a bit more about this topic in the coming week.
BTW, I’ve updated HFCD 4 this morning. It includes several bug fixes and some minor performance enhancements. The good news is that HFCD 4 is still a lot faster than the FB built-in compiler in most medium-to-large FB workspaces.