From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 588AE1F62E for ; Tue, 15 Jan 2019 00:16:06 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id D8007121751; Tue, 15 Jan 2019 09:16:02 +0900 (JST) Received: from o1678916x28.outbound-mail.sendgrid.net (o1678916x28.outbound-mail.sendgrid.net [167.89.16.28]) by neon.ruby-lang.org (Postfix) with ESMTPS id F067812141E for ; Tue, 15 Jan 2019 09:16:00 +0900 (JST) Received: by filter0140p3las1.sendgrid.net with SMTP id filter0140p3las1-30243-5C3D263F-9 2019-01-15 00:15:59.159339118 +0000 UTC m=+9121.364480407 Received: from herokuapp.com (ec2-54-197-82-100.compute-1.amazonaws.com [54.197.82.100]) by ismtpd0026p1iad2.sendgrid.net (SG) with ESMTP id rapP3oSgSeikppnL4xgJbw for ; Tue, 15 Jan 2019 00:15:59.004 +0000 (UTC) Date: Tue, 15 Jan 2019 00:15:59 +0000 (UTC) From: tenderlove@ruby-lang.org To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 66541 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 15393 X-Redmine-Issue-Author: tenderlovemaking X-Redmine-Sender: tenderlovemaking 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-SG-EID: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS4GkFWu6nkwI22b2wfSnRyrzWGBSdm+qVz3EP qAia74Sz/jHDLtKuqTVWlyBMCq+o1Zo95S6HBVSL//MJyOmNjSkZF+CYslcuFWS/V235b6Umn5Vzb1 +4I+0nOzWW/XIwq1Owy6yCMs4As2w8iXg8fK16mjqKLS7RKsLriEn34h1A== X-ML-Name: ruby-core X-Mail-Count: 91092 Subject: [ruby-core:91092] [Ruby trunk Feature#15393] Add compilation flags to freeze Array and Hash literals X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" Issue #15393 has been updated by tenderlovemaking (Aaron Patterson). Eregon (Benoit Daloze) wrote: > tenderlovemaking (Aaron Patterson) wrote: > > I thought about doing this with ".freeze", introducing a special instruction the same way we do for the `"string".freeze` optimization, but dealing with deoptization in the case someone monkey patches the method seems like a pain. > > I think it might semantically make some sense to ignore monkey-patching of `.freeze` (and `.deep_freeze`) for calls on literals, which would then avoid needing deoptimization for this (although deoptimization would be a flag check + the current logic as fallback, it doesn't seem so bad). > It's somewhat similar to String literals not calling String#initialize for instance (same for Array, Hash). > And it's probably a bad idea to override #freeze in the hope it would be used on frozen literals anyway, as of course this would only work if the monkey-patch is reliably loaded before everything else. > > Another issue is it's quite ugly to opt out of frozen array/hash literals, if a mutable copy is wanted: > > ```ruby > # frozen_hash_and_array_literal: true > my_mutable_data = { 'a' => ['b', { 'c' => 'd' }.dup].dup }.dup > ``` > > That's why I think `deep_freeze` would better express the intent in some cases, and be finer-grained: > > ```ruby > MY_CONSTANT = { 'a' => ['b', { 'c' => 'd' }] }.deep_freeze > my_mutable_data = { 'a' => ['b', { 'c' => 'd' }] } > > { :defaults => 'thing' }.deep_freeze.merge(some_hash) > ``` Yes, I totally agree. I think `deep_freeze` is going to be necessary for adoption of Guilds, and the code I'm proposing in this patch would be an optimization of the `deep_freeze` call on a literal. > and this would work regardless of what is the value to freeze (but only avoid allocations if it's all literals, otherwise a constant must be used). > > Furthermore, frozen literals don't allow composition or extraction in different constants: > ```ruby > # frozen_hash_and_array_literal: true > MY_KEY = 'a' > MY_CONSTANT = { MY_KEY => ['b', { 'c' => 'd' }] } # Not frozen, and breaks referential transparency > > MY_CONSTANT = { MY_KEY => ['b', { 'c' => 'd' }] }.deep_freeze # Works > ``` > > OTOH, "string".freeze has shown the magic comment is much nicer in many cases than adding "string".freeze in many places (at the price of making a mutable String not so nice, but those seem rarer). > It would be interesting to get an idea of what's a typical ratio of immutable/mutable Array and Hash literals, and what converting a codebase to use frozen Array/Hash literals would look like. Right. I'm not proposing adding the magic comment at all, just adding a parameter to the ISeq constructor that will allow you to "deep freeze" literals in the code passed to ISeq#new. ---------------------------------------- Feature #15393: Add compilation flags to freeze Array and Hash literals https://bugs.ruby-lang.org/issues/15393#change-76323 * Author: tenderlovemaking (Aaron Patterson) * Status: Open * Priority: Normal * Assignee: * Target version: ---------------------------------------- Hi, I would like to add VM compilation options to freeze array and hash literals. For example: ~~~ ruby frozen = RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_and_array_literal: true) { 'a' => ['b', { 'c' => 'd' }] } eocode puts frozen.disasm ~~~ Output is: ~~~ $ ./ruby thing.rb == disasm: #@thing.rb:0 (0,0)-(0,34)> (catch: FALSE) 0000 putobject {"a"=>["b", {"c"=>"d"}]} 0002 leave ~~~ Anything nested in the hash that can't be "frozen" will cause it to not be frozen. For example: ~~~ ruby not_frozen = RubyVM::InstructionSequence.compile(<<-eocode, __FILE__, nil, 0, frozen_string_literal: true, frozen_hash_and_array_literal: true) { 'a' => some_method } eocode puts not_frozen.disasm ~~~ Output: ~~~ $ ./ruby thing.rb == disasm: #@thing.rb:0 (0,0)-(0,24)> (catch: FALSE) 0000 putobject "a" 0002 putself 0003 opt_send_without_block , 0006 newhash 2 0008 leave ~~~ Eventually I would like to freeze array and hash literals in source code itself, but I think this is a good first step. The reason I want this feature is I think we can reduce some object allocations, and once Guilds are implemented, easily create immutable data. I've attached a patch that implements the above. (Also I think maybe "frozen_literals" would be a better name, but I don't want to imply that numbers or booleans are frozen too) Thanks! -- https://bugs.ruby-lang.org/