Wednesday, January 5, 2005

Reef fixes and memory profiling

WARNING: This blog entry was imported from my old blog on blogs.sun.com (which used different blogging software), so formatting and links may not be correct.



We've spent some time analyzing the problems that were reported in Reef.
There were a couple of issues. First is the one I've already described in a previous blog; projects with errors are not handled well when you restart the IDE (as after an IDE upgrade for example :-).




The second issue had to do with memory usage; a number of people reported hangs, which in all cases we've come across have turned out to be related to out of memory issues. I've already blogged about this a little bit, but essentially the max heap size was set too low. This became a problem for many of you when you upgraded to Reef, because with its additional features it consumed more of the available memory. Anyone whose projects were already near the memory limit suddenly got pushed above the limit, so Out-of-memory conditions started occurring. This also explains why for some, turning off the preview features helped, since that slightly reduces the memory used by the IDE.





profiler screenshot


However, in memory profiling looking for leaks we found that the CSS parser was consuming an unreasonable amount of memory. A little caching here, and little sharing there, and voila - the customer project is consuming 30% less memory... We're going to get these fixes to you as soon as possible; they're going to be put through a test cycle and then appear on the update center.



To analyze the memory usage, I used the
NetBeans memory profiler. It's really cool. I look forward to it being integrated in NetBeans 4.1, and the underlying VM technology integrated in one of the upcoming JDK 1.5 releases.




1 comment:

  1. Oooh, JVM profiler. Thanks for the link Tor -- I'm a sucker for graphs and charts!

    ReplyDelete