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=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham 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 5BABD1F44D for ; Fri, 12 Apr 2024 05:28:40 +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=xggUaFEr; 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=g6E5P1eB; dkim-atps=neutral Received: from nue.mailmanlists.eu (localhost [127.0.0.1]) by nue.mailmanlists.eu (Postfix) with ESMTP id AA61484254; Fri, 12 Apr 2024 05:28:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1712899712; bh=LMqxqQ45M9+L6PNMMrPHUacXdWvZEWjUFUlJ7IlsZ0c=; 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=xggUaFEr6TrlN2MKx98GO39Lxlghr/kD6bKsq4EOm3oHe4D6OEebJJiZ0jHlYnszg /LQdX3R+y5oF2yvW/cVUdEqbYwjU4QDPCsXPz87JlOgWoi6ILkG8p/K1ypuPNf0ig6 XMq+28Wug4uHE17Gmo1DyA691NeB2xbTBUxH/TH4= Received: from s.wfbtzhsv.outbound-mail.sendgrid.net (s.wfbtzhsv.outbound-mail.sendgrid.net [159.183.224.104]) by nue.mailmanlists.eu (Postfix) with ESMTPS id B5DDA8422E for ; Fri, 12 Apr 2024 05:28:29 +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=g6E5P1eB; 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=N5QLBp0HFCXwhSk2ANB6JF0XMN6IsqjWUCkNpx+2+0w=; b=g6E5P1eBD11HwY2e6Lr3sFb/uwOXSkbu03NaIU2Rol+YE1M/4yJGMXJk/P02B+UoE+DB gz6wAHr9PAyw5ghg1v15K9q7Ug8tbtJPsdr6iNfOIJCPnTPmeq41KE7a16HU2jhK78lgU5 kvbHqVwERfEyTG1PbrRD723N3ZeI2zEdquVTK4LdkyMBe/opupqbVU2fSOc0zKkaZsxOk1 OysSdG/RGXu9Y+K4ACONcEpTzSoTLIxbIpC0cz9ntHnMA/kE5M7fhI1wQ7KYlsIjl5ak6C E+8iSR2o6+f698jkoW4SS3Ow4/yVUtSbmHmGXhPwimtQI25RS+8MMZ4PYCilRg6w== Received: by filterdrecv-6d9df787bf-2r5jz with SMTP id filterdrecv-6d9df787bf-2r5jz-1-6618C67C-1 2024-04-12 05:28:28.797043121 +0000 UTC m=+2106161.822172622 Received: from herokuapp.com (unknown) by geopod-ismtpd-7 (SG) with ESMTP id cZUgLVMaQzyS6LXVB4pxMg for ; Fri, 12 Apr 2024 05:28:28.699 +0000 (UTC) Date: Fri, 12 Apr 2024 05:28:28 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Feature X-Redmine-Issue-Id: 20425 X-Redmine-Issue-Author: tenderlovemaking X-Redmine-Issue-Priority: Normal X-Redmine-Sender: ko1 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: 94096 X-SG-EID: =?us-ascii?Q?u001=2EbATEdfk2zDVGkqEmBpIo5H4n7Ev5v4PGlIEIJ8FEzfCkvwlGMFn=2FTmv+l?= =?us-ascii?Q?pwPr17bEITdo5x64lhfcVhbF8MZb6Dyaz=2FI0ahw?= =?us-ascii?Q?EAwJe2=2FlnBDz+QOZ0nMcKVuapxs5iYo1C1xycr2?= =?us-ascii?Q?ONUW01hK0G=2FtXLP6=2FyEfYohDikjtSmoQFWsk12a?= =?us-ascii?Q?RQSNgH3vdg38u6UvSCLYT7xG4QZaC+KLpmxJL+r?= =?us-ascii?Q?u8UfzdGTWbTido89IuuFg3HexSYClBC4jksjyL2?= =?us-ascii?Q?LXT6Xl5P=2F0wb40B2qEViglwmlQ=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: TAYPTPIMCAR6FF2LAZZ73B2VPQT6KXE4 X-Message-ID-Hash: TAYPTPIMCAR6FF2LAZZ73B2VPQT6KXE4 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:117501] [Ruby master Feature#20425] Optimize forwarding callers and callees List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "ko1 (Koichi Sasada) via ruby-core" Cc: "ko1 (Koichi Sasada)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20425 has been updated by ko1 (Koichi Sasada). Instead of introducing new rules and complex code, I think providing lightweight container than Array/Hash is better. Consider `def f(...) = g(...)`: * Introducing argument object (like JS) by imemo and pass it as a unique parameter for a method `def f(...)` * of course not visible objects from Ruby users. * argobj has memory buffer (argbuff) and copy all arguments (and CI) to argbuff. * calling another method with `g(...)` expand all arguments from argbuff. * argbuff memory management * argbuff is allocated from ractor local argbuff heap (4KB for example) by bump allocation. * if argbuff heap is not enough, all existing argobj copies their argubuff to malloc managed memory (evacuation) It takes (1) argobj object allocation and (2) 2 copies (1 for argbuff and 1 for calling g(), the original proposal only copies once at calling g()), so not ultimate lightweight, but simple. For `new` case, I think providing new `VM_METHOD_TYPE_OPTIMIZED` logic is better. ---------------------------------------- Feature #20425: Optimize forwarding callers and callees https://bugs.ruby-lang.org/issues/20425#change-107888 * Author: tenderlovemaking (Aaron Patterson) * Status: Open ---------------------------------------- [This PR](https://github.com/ruby/ruby/pull/10510) optimizes forwarding callers and callees. It only optimizes methods that only take `...` as their parameter, and then pass `...` to other calls. Calls it optimizes look like this: ```ruby def bar(a) = a def foo(...) = bar(...) # optimized foo(123) ``` ```ruby def bar(a) = a def foo(...) = bar(1, 2, ...) # optimized foo(123) ``` ```ruby def bar(*a) = a def foo(...) list = [1, 2] bar(*list, ...) # optimized end foo(123) ``` All variants of the above but using `super` are also optimized, including a bare super like this: ```ruby def foo(...) super end ``` This patch eliminates intermediate allocations made when calling methods that accept `...`. We can observe allocation elimination like this: ```ruby def m x = GC.stat(:total_allocated_objects) yield GC.stat(:total_allocated_objects) - x end def bar(a) = a def foo(...) = bar(...) def test m { foo(123) } end test p test # allocates 1 object on master, but 0 objects with this patch ``` ```ruby def bar(a, b:) = a + b def foo(...) = bar(...) def test m { foo(1, b: 2) } end test p test # allocates 2 objects on master, but 0 objects with this patch ``` ## How does it work? This patch works by using a dynamic stack size when passing forwarded parameters to callees. The caller's info object (known as the "CI") contains the stack size of the parameters, so we pass the CI object itself as a parameter to the callee. When forwarding parameters, the forwarding ISeq uses the caller's CI to determine how much stack to copy, then copies the caller's stack before calling the callee. The CI at the forwarded call site is adjusted using information from the caller's CI. I think this description is kind of confusing, so let's walk through an example with code. ```ruby def delegatee(a, b) = a + b def delegator(...) delegatee(...) # CI2 (FORWARDING) end def caller delegator(1, 2) # CI1 (argc: 2) end ``` Before we call the delegator method, the stack looks like this: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 4| # | 5| delegatee(...) # CI2 (FORWARDING) | 6| end | 7| | 8| def caller | -> 9| delegator(1, 2) # CI1 (argc: 2) | 10| end | ``` The ISeq for `delegator` is tagged as "forwardable", so when `caller` calls in to `delegator`, it writes `CI1` on to the stack as a local variable for the `delegator` method. The `delegator` method has a special local called `...` that holds the caller's CI object. Here is the ISeq disasm fo `delegator`: ``` == disasm: # local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 1] "..."@0 0000 putself ( 1)[LiCa] 0001 getlocal_WC_0 "..."@0 0003 send , nil 0006 leave [Re] ``` The local called `...` will contain the caller's CI: CI1. Here is the stack when we enter `delegator`: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 -> 4| # | CI1 (argc: 2) 5| delegatee(...) # CI2 (FORWARDING) | cref_or_me 6| end | specval 7| | type 8| def caller | 9| delegator(1, 2) # CI1 (argc: 2) | 10| end | ``` The CI at `delegatee` on line 5 is tagged as "FORWARDING", so it knows to memcopy the caller's stack before calling `delegatee`. In this case, it will memcopy self, 1, and 2 to the stack before calling `delegatee`. It knows how much memory to copy from the caller because `CI1` contains stack size information (argc: 2). Before executing the `send` instruction, we push `...` on the stack. The `send` instruction pops `...`, and because it is tagged with `FORWARDING`, it knows to memcopy (using the information in the CI it just popped): ``` == disasm: # local table (size: 1, argc: 0 [opts: 0, rest: -1, post: 0, block: -1, kw: -1@-1, kwrest: -1]) [ 1] "..."@0 0000 putself ( 1)[LiCa] 0001 getlocal_WC_0 "..."@0 0003 send , nil 0006 leave [Re] ``` Instruction 001 puts the caller's CI on the stack. `send` is tagged with FORWARDING, so it reads the CI and _copies_ the callers stack to this stack: ``` Executing Line | Code | Stack ---------------+---------------------------------------+-------- 1| def delegatee(a, b) = a + b | self 2| | 1 3| def delegator(...) | 2 4| # | CI1 (argc: 2) -> 5| delegatee(...) # CI2 (FORWARDING) | cref_or_me 6| end | specval 7| | type 8| def caller | self 9| delegator(1, 2) # CI1 (argc: 2) | 1 10| end | 2 ``` The "FORWARDING" call site combines information from CI1 with CI2 in order to support passing other values in addition to the `...` value, as well as perfectly forward splat args, kwargs, etc. Since we're able to copy the stack from `caller` in to `delegator`'s stack, we can avoid allocating objects. ## Why? I want to do this to eliminate object allocations for delegate methods. My long term goal is to implement `Class#new` in Ruby and it uses `...`. I was able to implement `Class#new` in Ruby [here](https://github.com/ruby/ruby/pull/9289). If we adopt the technique in this patch, then we can optimize allocating objects that take keyword parameters for `initialize`. For example, this code will allocate 2 objects: one for `SomeObject`, and one for the kwargs: ```ruby SomeObject.new(foo: 1) ``` If we combine this technique, plus implement `Class#new` in Ruby, then we can reduce allocations for this common operation. -- 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/