[#86787] [Ruby trunk Feature#14723] [WIP] sleepy GC — ko1@...

Issue #14723 has been updated by ko1 (Koichi Sasada).

13 messages 2018/05/01
[#86790] Re: [Ruby trunk Feature#14723] [WIP] sleepy GC — Eric Wong <normalperson@...> 2018/05/01

ko1@atdot.net wrote:

[#87095] [Ruby trunk Feature#14767] [PATCH] gc.c: use monotonic counters for objspace_malloc_increase — ko1@...

Issue #14767 has been updated by ko1 (Koichi Sasada).

9 messages 2018/05/17

[ruby-core:86987] Re: [Ruby trunk Bug#14745] High memory usage when using String#replace with IO.copy_stream

From: Eric Wong <normalperson@...>
Date: 2018-05-11 04:26:27 UTC
List: ruby-core #86987
janko.marohnic@gmail.com wrote:
> ~~~ ruby
>   def read(length, outbuf)
>     chunk = @io.read(length)
> 
>     if chunk
>       outbuf.replace chunk
>       chunk.clear

Elaborating on my previous comment,  chunk.clear is a no-op in
this case because the shared frozen string is still in play and
now used by outbuf.

>     else
>       outbuf.clear

Likewise, the final #clear is also no-op because the
hidden+frozen string is still floating around waiting to be
GC-ed.

>     end
> 
>     outbuf unless outbuf.empty?
>   end
> ~~~

I don't think you need IO.copy_stream or IO#write to trigger, even.

~~~ ruby
io = FakeIO.new("a" * 50*1024*1024) # 50MB
buf = ''.b
while z = io.read(16384, buf)
end
~~~

I tried playing with shortening object lifetimes, but I guess GC
is not aggressive enough by default to matter.

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>

In This Thread