Forum: Ruby-core Objects in large arrays are leaked

18813f71506ebad74179bf8c5a136696?d=identicon&s=25 unknown (Guest)
on 2014-02-25 11:12
(Received via mailing list)
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

 If I were to allow >=64K client connections on my public yahns
 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

* 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 <<; a.pop }
# process RSS stays stable

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

It seems to be related to this bit of code:
18813f71506ebad74179bf8c5a136696?d=identicon&s=25 Eric Wong (Guest)
on 2014-03-29 07:40
(Received via mailing list)
ko1: may I commit the removal of special case for large array/hash?

* gc.c (rb_gc_writebarrier): remove special case for large hash/array
git:// gc-nomagic

I strongly believe there should no magic based on size.
This topic is locked and can not be replied to.