Fix memory leak for filters with keyword arguments

[peterzhu2118]

The push_keywords_obj (which is a TypedData object) has its data pointer set to NULL and is never freed, which leaks memory. The following script demonstrates the issue:

require "liquid"
require_relative "lib/liquid/c"

1_000_000.times do
  Liquid::Template.parse("{{ value | default: 'None', allow_false: true }}")
end

puts `ps -o rss -p #{$$}`.chomp.split("\n").last.to_i

Before this patch, the output is 199620, after this patch, the output is 124160.

We shouldn't be using rb_gc_force_recycle anyways because it doesn't clean up resources and we should let the GC decide when to free objects (rather than forcing the GC to reclaim the object).

[dylanahsmith]

The push_keywords_obj (which is a TypedData object) has its data pointer set to NULL and is never freed, which leaks memory.

Good catch, I opened #158 as an alternative fix though.

We shouldn't be using rb_gc_force_recycle anyways because it doesn't clean up resources and we should let the GC decide when to free objects (rather than forcing the GC to reclaim the object).

It doesn't seem like that rb_gc_force_recycle is inherently bad (e.g. ruby uses it internally), but I had used it the wrong way. If I understand correctly, it doesn't require GC to reclaim the object, it is eagerly reclaiming the object so that it doesn't need GC to reclaim it.

[peterzhu2118]

@dylanahsmith While there are several places in Ruby that use rb_gc_force_recycle, the Ruby core team does not like it as it is difficult to maintain and makes changes in the GC difficult (e.g. ruby/ruby#4329 (comment))

[dylanahsmith]

Oh, apparently it is also "slow, now a day" according to the comment you linked to. Perhaps that is because it can't simply reuse objects with the current GC algorithm.