From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET,SPF_HELO_PASS, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id F2C091F44D for ; Mon, 15 Apr 2024 20:02:27 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; secure) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=fTJzLcjB; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=D1FbT/WI; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id 2B59584318; Mon, 15 Apr 2024 20:02:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1713211339; bh=VIx8DBXgV+LVFryMKQoup0P91a/pfGtWLeNPKepQ9sk=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=fTJzLcjBAVp1qVOqDIOs5i3w+nevPr4so70r9NXZhRSrz56f72okv9D6viMxuHs8J ieiz6xnWT9K1UpFst1vikXT57pc8YAvSZWXP1OWT3BggwWwJU8w8T/YH7chJ22oaNQ 9YHEXeEzHKXdMx7K36Xv8/lGKaKc1FWFU17eGwP0= Received: from s.wrqvtzvf.outbound-mail.sendgrid.net (s.wrqvtzvf.outbound-mail.sendgrid.net [149.72.126.143]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 7241E84254 for ; Mon, 15 Apr 2024 20:02:15 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=D1FbT/WI; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=pKFyvEaHpNOcSFiSnPMkRfMLTO3vbh+xdr5Tvm+Ly18=; b=D1FbT/WI5uVmK8BsynYql0dMa2tUWgCVcp4XqEWYsWICriqpauwZns/CWkmmMDrA3COw B8GHBpA0LKqQ/CK1rFsc3v2Yz7dZO3l7WTFB9HWNXjRqXxiab0uU2JPZ/tN/XfjpXeI4Rv eNW9SFv3N+LDUq/SR4v5pHNfnx5HbGhWuoPt/2dCj9qk+r4JXZJKbMBhQ5FOtCG0Pu24hQ zp2ABQtTdDj5NV/FHSlZB8IlylkyPf3BwrmkgHw5mVHBhpXrHJwClcxhnvFBBRjjh8V0Vw L3IJPh8+CVWHoy2lFT0iKV5MyqKJX3hpu2dmhXcc2aG33df3FVYPdsLnAfrR+vDw== Received: by recvd-8c7b9fb4f-8dpmh with SMTP id recvd-8c7b9fb4f-8dpmh-1-661D87C6-15 2024-04-15 20:02:14.431385581 +0000 UTC m=+252093.902361671 Received: from herokuapp.com (unknown) by geopod-ismtpd-29 (SG) with ESMTP id ETRN5cflQ7CCPQXKUUk-yQ for ; Mon, 15 Apr 2024 20:02:14.394 +0000 (UTC) Date: Mon, 15 Apr 2024 20:02:14 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20351 X-Redmine-Issue-Author: eightbitraptor X-Redmine-Issue-Priority: Normal X-Redmine-Sender: eightbitraptor X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 94109 X-SG-EID: =?us-ascii?Q?u001=2E9VAa+KF84+ACjWkSb8mcy8gS+fYyyXFRcDVQpXgr7nDVEZYc6+Pq9ajFu?= =?us-ascii?Q?WmefySeLz3zn3rchgcytbyt4srfHH8FuYLgsYRD?= =?us-ascii?Q?3WTVvJnqa+pjLp+YiWWS7sJrBg1gctizUsBV8m7?= =?us-ascii?Q?ej1=2FfH2V7NY2MKH46LeyQFdICaew2i0jN=2FIup5Y?= =?us-ascii?Q?u3JqhuAf9Jha1Hw3xbEhC92PsgJkOBdZzISaBaA?= =?us-ascii?Q?crRD8wfl9ncXAGzkPc2kQipzwe8SqMutKj9tfZP?= =?us-ascii?Q?5yYGMauqw4s=2Fs8VvjvX8gQWVJzVN0t4O=2F9HHnOi?= =?us-ascii?Q?baNoiiYk=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: 6VA5AIPIZTJNMSHXFMQXKYPPKYBEEGFH X-Message-ID-Hash: 6VA5AIPIZTJNMSHXFMQXKYPPKYBEEGFH X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:117514] [Ruby master Feature#20351] Optionally extract common GC routines into a DSO List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "eightbitraptor (Matthew Valentine-House) via ruby-core" Cc: "eightbitraptor (Matthew Valentine-House)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20351 has been updated by eightbitraptor (Matthew Valentine-House). Closed by https://github.com/ruby/ruby/pull/10456 ---------------------------------------- Feature #20351: Optionally extract common GC routines into a DSO https://bugs.ruby-lang.org/issues/20351#change-107903 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open ---------------------------------------- **UPDATE: Based on feedback on the original PR (thank you @katei and @nobu) we have changed our approach to this project.** **An updated PR can be found here: [[GH #10456]](https://github.com/ruby/ruby/pull/10456)** --- ~~[Github PR#10302](https://github.com/ruby/ruby/pull/10302)~~ **NOTE: This proposal does not change the default build of Ruby, and therefore should NOT cause performance degradation for Ruby built in the usual way** Our long term goal is to standardise Ruby's GC interface, allowing alternative GC implementations to be used. This will be acheived by optionally building Ruby's GC as a shared object; enabling it to be replaced at runtime using using `LD_LIBRARY_PATH`. eg: ``` LD_LIBRARY_PATH=/custom_gc_location ruby script.rb ``` This ticket proposes the first step towards this goal. A new experimental build option, `--enable-shared-gc`, that will compile and link a module into the built `ruby` binary as a shared object - `miniruby` will remain statically linked to the existing GC in all cases. Similar methods of replacing functionality relied on by Ruby have precedent. `jemalloc` uses `LD_PRELOAD` to replace `glibc` provided `malloc` and `free` at runtime. Although this project will be the first time a technique such as this has been used to replace core Ruby functionality. This flag will be marked as experimental & **disabled by default**. [The PR linked from this ticket](https://github.com/ruby/ruby/pull/10302) implements the new build flag, along with the absolute minimum code required to test it's implementation (a single debug function). The implementation of the new build flag is based on the existing implementation of `--enable-shared` and behaves as follows: - `--enable-shared --enable-shared-gc` This will build both `libruby` and `librubygc` as shared objects. `ruby` will link dynamically to both `libruby` and `librubygc`. - `--disable-shared --enable-shared-gc` This will build `librubygc` as a shared object, and build `libruby` as a static object. `libruby` will link dynamically to `librubygc` and `ruby` will be statically linked to `libruby`. - `--disable-shared-gc` **This will be the default**, and when this case is true the build behaviour will be exactly the same as it is currently. ie. the existing Ruby GC will be built and linked statically into either `ruby` or `libruby.so` depending on the state of `--enable-shared`. We are aware that there will be a small performance penalty from moving the GC logic into a shared object, but this is an opt-in configuration turned on at build time intended to be used by experienced users. Still, we anticipate that, even with this configuration turned on, this penalty will be negligible compared the the benefit that being able to use high performance GC algorithms will provide. This performance penalty is also the reason that **this feature will be disabled by default**. There will be no performance impact for anyone compiling Ruby in the usual manner, without explicitly enabling this feature. We have discussed this proposal with @matz who has approved our work on this project - having a clear abstraction between the VM and the GC will enable us to iterate faster on improvements to Ruby's existing GC. ## Motivation In the long term we want to provide the ability to override the current Ruby GC implementation in order to: * Experiment with modern high-performance GC implementations, such as Immix, G1, LXR etc. * Easily split-test changes to the GC, or the GC tuning, in production without having to rebuild Ruby * Easily use debug builds of the GC to help identify production problems and bottlenecks without having to rebuild Ruby * Encourage the academic memory management research community to consider Ruby for their research (the current work on [MMTk & Ruby](https://github.com/mmtk/mmtk-ruby) is a good example of this). ## Future work The initial implementation of the shared GC module in this PR is deliberately small, and exists only for testing the build system integration. The next steps are to identify boundaries between the GC and the VM and begin to extract common functionality into this GC wrapper module to serve as the foundation of our GC interface. ## Who's working on this - @eightbitraptor - @tenderlovemaking - @peterzhu2118 - @eileencodes -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/