[#27003] [Bug #2422] splat operator fails on array of 1 element — Raul Parolari <redmine@...>

Bug #2422: splat operator fails on array of 1 element

12 messages 2009/12/02

[#27025] [Backport #2431] StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n" — Hiroshi NAKAMURA <redmine@...>

Backport #2431: StringIO#{gets,readlines} with "" (paragraph mode) trims last "\n"

8 messages 2009/12/04

[#27086] [Feature #2454] OpenSSL has no maintainer — Yui NARUSE <redmine@...>

Feature #2454: OpenSSL has no maintainer

16 messages 2009/12/07

[#27120] #to_enum ignores block? — Roger Pack <rogerdpack@...>

Is #to_enum ignoring its block expected?

11 messages 2009/12/09

[#27135] better GC? — Roger Pack <rogerdpack@...>

Could I put in a small plea for a better GC?

56 messages 2009/12/10
[#27136] Re: better GC? — Yukihiro Matsumoto <matz@...> 2009/12/11

Hi,

[#27476] Re: better GC? — Paul Brannan <pbrannan@...> 2010/01/07

On Fri, Dec 11, 2009 at 09:07:16AM +0900, Yukihiro Matsumoto wrote:

[#27477] Re: better GC? — Eero Saynatkari <ruby-ml@...> 2010/01/07

Excerpts from Paul Brannan's message of Thu Jan 07 21:53:34 +0200 2010:

[#27563] Re: better GC? — Brent Roman <brent@...> 2010/01/12

[#27199] [Backport #2488] thread usage can result in bad HANDLE — Roger Pack <redmine@...>

Backport #2488: thread usage can result in bad HANDLE

12 messages 2009/12/16

[#27286] [Bug #2515] Array#select! — Roger Pack <redmine@...>

Bug #2515: Array#select!

17 messages 2009/12/22

[#27327] [Bug #2531] Ruby 1.8.7-p248 fails to cross-compile same version — Luis Lavena <redmine@...>

Bug #2531: Ruby 1.8.7-p248 fails to cross-compile same version

9 messages 2009/12/25

[#27360] [Feature #2542] URI lib should be updated to RFC 39886 — Marc-Andre Lafortune <redmine@...>

Feature #2542: URI lib should be updated to RFC 39886

15 messages 2009/12/31

[ruby-core:27146] Re: Ruby's GC

From: Evan Phoenix <evan@...>
Date: 2009-12-11 17:26:52 UTC
List: ruby-core #27146
On Dec 11, 2009, at 7:08 AM, Yukihiro Matsumoto wrote:

> Hi,
> 
> In message "Re: [ruby-core:27144] Re: Ruby's GC"
>    on Fri, 11 Dec 2009 23:57:24 +0900, Rick DeNatale <rick.denatale@gmail.com> writes:
> 
> |I suspect that the write barrier can be implemented rather efficiently
> |depending on how memory layout is done. You need to be able to
> |efficiently distinguish between mutations to references in old objects
> |(which need to be remembered) and mutations in new objects, which
> |don't.
> |
> |One interesting problem, is what effect a copying GC would have on the
> |API to C extensions, since object addresses would no longer be stable
> |over time.
> 
> Non conservative GC would damage almost all C extensions for Ruby.
> I don't think it's acceptable for CRuby.

A copy collector would also break almost all C extensions, because it's common for people to store a reference to an object somewhere "secret", and then store in somewhere normal to keep it alive. Because the current GC doesn't move objects, the "secret" reference stays valid as long as the object lives.

With a copy collector, all references need to be fixed up, so the "secret" references would be invalidated.

For Rubinius, we implemented an indirection layer between the C extensions and the GC that uses handles. These handles don't move, so C extensions can store "secret" references to them and GC can still move things behind the scene, so long as the handle is internally updated.

> Regarding of copying GC, one thing I have interest is how its
> copy-on-write unfriendliness effect the performance under Web
> environment.
> 
> 							matz.
> 
> 


In This Thread