On Thu, Oct 18, 2012 at 9:53 PM, Nabeel S. <[email protected]> wrote: > Hi all, > > I've been working on a C++ extension for node, that takes an object, and > then transforms it into a protocol buffer message, and then returns a Buffer > object. It works great, and it's fast. There are some strange patterns in > the heap total/heap used that I'm trying to understand, and figure out if I > should be worried about them. > > Here are two runs, one is 30 seconds, and the other is two minutes, of the > module running the encode and decode (as separate runs). > > http://i.imgur.com/i7orl.png <- 30 seconds > http://i.imgur.com/KVGV5.png <- two minutes > http://i.imgur.com/cYwyW.png <- another 30 second run, this shows a > different pattern that would make more sense > > So, am I looking at a memory leak here? According to node-memwatch > (https://github.com/lloyd/node-memwatch), there is no leak, when running it > against the same tests. > > So, I'm curious as to what that pattern means. The code has an encode and > decode function. They retrieve the protocol-buffers class based on > parameters passed in, and then instantiate a class that will process the > message, along with the parameters. It uses Handles and Locals within the > class, and then the class returns a Handle<Object> with a FastBuffer (for an > encode), and a nested Handle<Object> with all of the properties on decode. I > don't use the node::Buffer class (valgrind was showing a leak there; I > couldn't free the instance since the value was being pointed to by a > Handle). It's nothing too fancy, just uses Reflection and Descriptors to > recursively pass an Object that's passed by reference (bool > NodePBMsg::readProtoObject(protobuf::Message *msg, Handle<Object> > &return_data)) > > Valgrind does show leaks this, no matter how many iterations or for however > long it runs: > > ==4202== HEAP SUMMARY: > ==4202== in use at exit: 98,379 bytes in 1,589 blocks > ==4202== total heap usage: 173,296 allocs, 171,707 frees, 15,079,515 bytes > allocated > ==4202== > ==4202== LEAK SUMMARY: > ==4202== definitely lost: 4,509 bytes in 40 blocks > ==4202== indirectly lost: 8,192 bytes in 1 blocks > ==4202== possibly lost: 20,922 bytes in 426 blocks > ==4202== still reachable: 64,756 bytes in 1,122 blocks > ==4202== suppressed: 0 bytes in 0 blocks > ==4202== Rerun with --leak-check=full to see details of leaked memory > ==4202== > ==4202== For counts of detected and suppressed errors, rerun with: -v > ==4202== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
V8 doesn't clean up on exit (and neither does Node), the idea being that it's wasted time because the operating system will reclaim the memory anyway. The downside is that it makes Valgrind less useful, of course. I don't see anything untoward in the graphs, it looks like the garbage collector is doing its job. If you repeatedly hit the high water mark, it will (within reason) try to grow the heap. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
