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/

Attachment: pgp0PMt9ATWz_.pgp
Description: PGP signature

Reply via email to