On Thu, Jan 22, 2015 at 12:08:52PM -0500, Rafael Schloming wrote: > The most important thing to get worked out for this is the memory > management semantics between C and Ruby. From what I can tell from your > branch, it looks like you haven't done that yet. <snip>
My initial readings into how Ruby handles object references initially lead me to believe that, with Swig, we're receiving some benefit already WRT object management. Since Ruby uses mark and sweep rather than reference counts, when a Ruby object (or an C object wrapped by Swig as a Ruby object) goes out of reference then it'll get garbage collected. But I won't lie: there might be some subtle detail I'm missing here. I played around with this last night after your suggestion and wrote some stuff on a side branch [1]. It's a simple test that uses the following types: * pn_rubyref_t - C type in Proton that's wrapped by Swig; holds a void * reference to any kind of object * Farkle - a pure Ruby class I then wrote a simple app that creates 1M instances of rb_rubyref_t and 1M instances of Farkle as assigns a Farkle to each rb_rubyref_t. It then puts them each into an array, which is size limited to 100k entries (to allow any GC to run while the app is going). I also added finalizer function to Farkle that just outputs some text when the object is being garbage collected. What I see as the app runs is the output of the Farkle instances being garbage collected while there are still instances being created. The app then ends by sleeping and then exiting. Before and after sleeping the app outputs the number of objects (via ObjectSpace) exist for each type. Running it multiple times I see all of the pn_rubyref_t and Farkle instances being cleaned up, no memory leaks. I then changed things to make a circular reference between Farkle and pn_rubyref_t. Re-ran the tests and still see the objects getting cleaned up. I also ran top to keep an eye on memory usage for the ruby-mri process. O_o (1) [J:0/1028] mcpierce@mcpierce-laptop:cmake (0.3-fedora) $ top -b | grep ruby-mri 19989 mcpierce 20 0 188964 23228 6380 S 53.3 0.3 0:00.55 ruby-mri 19989 mcpierce 20 0 202644 36892 6380 S 18.3 0.5 0:01.10 ruby-mri 19989 mcpierce 20 0 207492 41784 6380 R 19.9 0.5 0:01.70 ruby-mri 19989 mcpierce 20 0 227748 62108 6380 S 17.6 0.8 0:02.23 ruby-mri 19989 mcpierce 20 0 229796 64020 6380 R 22.3 0.8 0:02.90 ruby-mri 19989 mcpierce 20 0 233096 67188 6380 R 57.1 0.8 0:03.42 ruby-mri 19989 mcpierce 20 0 233096 67188 6380 S 0.7 0.8 0:03.44 ruby-mri 19989 mcpierce 20 0 233096 67188 6380 S 0.0 0.8 0:03.44 ruby-mri 19989 mcpierce 20 0 233096 67188 6380 S 0.0 0.8 0:03.44 ruby-mri 19989 mcpierce 20 0 233096 67188 6380 S 1.3 0.8 0:03.48 ruby-mri 19989 mcpierce 20 0 235340 69564 6380 R 48.5 0.9 0:04.94 ruby-mri 19989 mcpierce 20 0 235340 69564 6380 S 47.5 0.9 0:06.37 ruby-mri 19989 mcpierce 20 0 235340 69564 6380 R 50.5 0.9 0:07.89 ruby-mri 19989 mcpierce 20 0 235340 69564 6380 S 48.0 0.9 0:09.34 ruby-mri I only show those lines since, after that point, the virtual memory footprint didn't grow for the run os the apps run. [1] https://github.com/mcpierce/Proton/tree/c-to-ruby-reference-gc-check -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
pgp0PMt9ATWz_.pgp
Description: PGP signature
