ruby: object not cleaned by GC when it creates a thread - ruby

Question

Class owning a thread doesn't get garbage collected
I have a ruby service that needs to stream an object from S3 to somewhere else, the files get large and I don't want to store them as a file, so I wrote a simple class to buffer parts of the object for it to be used as an IO object by other parts of the code.
Essentially it looks like this, and full code avail in Gist linked below:
class S3ObjectStream
attr_reader :s3_client, :object, :size
def initialize(bucket, key, part_size: 5 * 1024 * 1024, num_threads: 5)
#s3_client = Aws::S3::Client.new(...)
#object = Aws::S3::Object.new(bucket_name: bucket, key:, client: #s3_client)
#io = StringIO.new
#size = #object.content_length
initialize_parts
start_parts
ObjectSpace.define_finalizer(self,
self.class.method(:finalize).to_proc)
end
def self.finalize(id)
puts "S3ObjectStream #{id} dying"
end
def read(size, out_buf=nil)
# Simplified, checks if more mem needed from parts
get_mem if need_more
#io.read(size, out_buf)
end
def need_more
#check byte ranges
end
def get_mem
# Simplified...
part = #parts.shift
#io.rewind
#io << part.data
start_next_part
end
def initialize_parts
#parts = []
# Determine # of parts required
# Create instances of them
nparts.each do
part = DataPart.new(...)
#parts.push_back(part)
end
end
def start_parts
# Start downloading parts concurrently by num of threads or total parts
# These vars are set in initialize_parts, not shown in simplified code
num_to_start = [#num_parts, #num_threads].min
#parts.each_with_index do |part, i|
break if i == num_to_start
part.start
end
end
def start_next_part
#parts.each do |part|
next if part.started?
part.start
break
end
end
end
class DataPart
def initialize(s3_object, start_byte, end_byte)
#s3_object = s3_object
#start_byte = start_byte
#end_byte = end_byte
#range = "bytes=#{#start_byte}-#{#end_byte}"
ObjectSpace.define_finalizer(self,
self.class.method(:finalize).to_proc)
end
def self.finalize(id)
puts "DataPart #{id} dying"
end
def start
#thread = Thread.new do
#part_data = #s3_object.get(range: #range).body.read
nil # Don't want the thread to hold onto the string as Thread.value
end
end
def data
#thread.join
#part_data
end
end
The issue we're running into is the DataPart objects don't seem to be cleaned up by the garbage collection.
My understanding is once the DataPart goes out of scope in get_mem (shifted off the array, then leaves scope of the method), it should be unreachable and marked for cleaning.
Initially we were running into memory issues (graphs below) where the whole file was being held in memory. Adding the nil to the DataPart thread in start reduced the memory usage, but we were still seeing the objects stay around forever.
Here is a graph of the memory usage of this script
Adding destructor prints to the objects showed all the DataPart objects that were created weren't destroyed until the program exited even when the S3ObjectStreams that owned those objects and the arrays of them were being destroyed as expected.
gist showing test code and logs of objects being destroyed
When we remove the thread from start and do the part downloading in serial, the DataPart objects get destroyed as expected during runtime GC runs. But this obviously adds a ton of time to the whole process.
Graph of the memory usage after removing the thread
My question is, what would cause these DataParts to stick around with the inclusion of a thread? Is there a circular dependency here that I'm not understanding between the thread objects and the owning DataParts?

Answer 1

Rather than some objects not being garbage collected, I'd rather assume that your StringIO object in #io just gets larger on each read, since you append the data there in S3ObjectStream#get_mem.
As StringIO is basically just a normal String with a different interface to work like an IO object, what happens here is that you are just increasing the size of the underlying string, without ever releasing the read data again. Please be aware that with a StringIO object, just reading data from it will not delete previously read data from the String; you can always call rewind on it to read everything from the beginning again.
To avoid this, you should probably try to get rid of the #io object altogether and just use a simple String object. In get_mem, you can then append data to this string. In read, you can use String#byteslice to get up to size bytes of data and remove this read data from the buffer. That way, your buffer will not grow unbounded.
This can look like this:
class S3ObjectStream
def initialize(bucket, key, part_size: 5 * 1024 * 1024, num_threads: 5)
# ...
# a mutable string in binary encoding
#buffer = +"".force_encoding(Encoding::BINARY)
end
def get_mem
part = #parts.shift
#buffer << part.data
end
def read(size, out_buf = nil)
# Simplified, checks if more mem needed from parts
get_mem if need_more
data = #buffer.byteslice(0, size)
if out_buf
out_buf.replace data
out_buf
else
data
end
end
end
The out_buf is more or less useless in this implementation though and probably doesn't help in nay way. But likely, it doesn't hurt either.
Note that neither this construct nor your previous StringIO object is thread-safe. If you are thus appending to and/or reading from the #buffer from multiple concurrent threads, you need to add appropriate mutexes.
In addition to the #io issue, it also appears from tyour simplified code, that you are starting to get all parts in parallel, each in its own thread. Thus, each DataPart object hold its read data in memory in the #part_data variable. As you initialize all DataPart objects for your data in parallel at the start, your memory will grow to contain all parts anyway. The cobstructiuon wiuth partially getting a data part from the #parts array and appending its data to a buffer is thus rather pointless.
Instead, you probably have to only get a few DataParts (or one at a time) as they are consumed and continue creating/fetching additional DataParts as you read the data.