Issue #9518 has been updated by Eric Wong.


 The yahns HTTP server uses a long-lived fdmap array to map
 Fixnum(fileno) -> IO connections.
 This array exists prevent GC from sweeping IOs (because IOs are watched
 by Linux epoll and not markable w/o an Array to store them).
 
 64K+ connections (array size) is attainable with yahns.  The long-lived
 fdmap array lifetime should not infect the short lived client
 connections.
 
 If I were to allow >=64K client connections on my public yahns instance,
 clients will cause memory leaks/waste.
 
 (yahns supports infinitely-lived connections, but in
  practice, clients connections tend to be short-lived).

----------------------------------------
Bug #9518: Objects in large arrays are leaked
https://bugs.ruby-lang.org/issues/9518#change-45465

* Author: Charlie Somerville
* Status: Open
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
* ruby -v: ruby 2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0]
* Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
a = [nil] * 131071
loop { a << Object.new; a.pop }
# process RSS stays stable

a = [nil] * 131072
loop { a << Object.new; a.pop }
# process RSS grows quickly and never falls

It seems to be related to this bit of code: https://github.com/github/ruby/blob/2.1/gc.c#L4764-4766



-- 
http://bugs.ruby-lang.org/