Showing posts with label memory leak. Show all posts
Showing posts with label memory leak. Show all posts

Tuesday, January 5, 2010

DZ 3.3.2 "Leakplug" Release Is Out

Changes since 3.3.1

  • (cosmetic, UI) Pressing +/- on the keyboard will now cycle through all available Android screen sizes (in pixels);
  • (fault tolerance) Hardware will now go into "power off" state upon DZ process termination;
  • (JMX) Individual dampers can now be monitored via JMX;
  • (hardware driver) One logical damper can now control multiple physical dampers (more than one register/damper per zone);
  • (optimization) 1-Wire and servo controller drivers now use less heap memory in favor of local variables = less garbage collection chatter;
  • (bugfix) On/off zone switch wors as designed now;
  • (bugfix) Voting zone switch works as designed now;
  • (bugfix) All zones must now be satisfied before the HVAC run ends, not just the one that initiated th run and the ones that happened to enter "calling" state before the first zone was satisfied;
  • (critical bugfix) Removed a memory leak in 1-Wire driver code;
  • (critical bugfix) Removed a memory leak in Servomaster code.

Servomaster 0.8.2.3 released

CHANGES

  • Minor: Parallax family driver code was optimized to reduce garbage collection chatter;
  • Major: Plugged a memory leak causing Servomaster to blow DZ out of memory. This leak was occurring every time the transition controller was being engaged. Root cause of the leak was the missing NDC.remove() at the end of the thread life.

Sunday, January 3, 2010

Memory Leak Hunt: Aftermath

Q: How much memory does DZ need to run?

A: Within JVM, less than 6MB of heap memory and about 19MB of non-heap, total 25MB - that is with all the features turned on, including JMX and console. Take a look at the picture below.

-Xms4m -Xmx4m

At the same time, JVM takes 177MB virtual memory, 57MB resident, and 10MB shared.

Q: How are you planning to prevent memory leaks in the future?

A: Starting with the next release (3.3.2), DZ JVM will be artificially constrained (-Xms4m -Xmx4m) to make sure that if it blows out of memory, it does it very fast and the leak can be identified and reported immediately.

Q: Will it affect system performance?

A: A little bit, you probably shouldn't care. Garbage collection will be happening once every few minutes instead of once every few hours. After you've ran DZ for a few hours (a day for most paranoid) in minimal configuration, you can safely remove the restriction - instructions will be provided within dz-runner script. Keep in mind, though, that amount of memory that JVM is taking out of the system may be higher if you do that, now, that may affect the system performance.

Q: How did you find the leak?

A: It was a trivial sequence of jmap and jhat runs (details at Monitoring and Managing Java SE 6 Platform Applications). In addition, some small and frequent memory allocations in OWAPI were replaced with local variables, to reduce garbage collection chatter.

Q: You're saying the leak is gone, but I keep getting OutOfMemoryException!

A: Possible. Leak free status was verified for DZ core, 1-Wire sensor driver, and Parallax servo controller driver running on Sun's JDK 1.6.0_17 under Ubuntu 9.10. First thing you need to do is to submit a detailed report including your hardware and platform details. jmap file (see the above link) right after the start and some time before the OutOfMemoryException will be much appreciated.

Friday, January 1, 2010

Early Access: Memory Leaks Plugged

Two major memory leaks were plugged this week:

  • One in dz3-owapi module (related to the fact that OWAPI code was instantiating device containers on every browse() (that'll be about once a minute);
  • One in Servomaster transition controller code (NDC.remove() wasn't called at the end of the thread life).
Code is available in Subversion (make sure you get both DZ and Servomaster updates.

Release will follow shortly.