Forum: Ruby-core Objects in large arrays are leaked

308cbef6e86dfc49cce3b2d4cf42aedc?d=identicon&s=25 unknown (Guest)
on 2014-02-25 09:49
(Received via mailing list)
Issue #9518 has been updated by Koichi Sasada.


Yes, you are right. WB (write barrier) strategy doesn't care such case.

How many such program?
If it is popular case, we can care about it.



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

* 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
18813f71506ebad74179bf8c5a136696?d=identicon&s=25 Eric Wong (Guest)
on 2014-02-25 11:06
(Received via mailing list)
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).
This topic is locked and can not be replied to.