Issue #15393 has been updated by tenderlovemaking (Aaron Patterson).


Eregon (Benoit Daloze) wrote:
> One alternative idea which would achieve a similar goal is having #deep_freeze on core types, and recognizing `{ 'a' => ['b', { 'c' => 'd' }] }.deep_freeze`.
> This would be more general, since it would also work for freezing non-constant/non-literal data structures.

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.

The reason I went this direction first is that it side steps the deoptimization problem, and if we want to support a ".deep_freeze" method later we can.  I imagine the implementation would be a branch where one of the branches is the same `putobject` instruction that I have in this patch.

Anyway, I think the advantages of this patch are:

1. No new methods like "deep_freeze", so you can try this with existing code
2. Any code you write that works with these flags enabled will also work with them disabled (vs deep_freeze that isn't on existing Rubys)
3. This patch should be forward compatible when we figure out what "deep_freeze" solution we're going to have in the future

> I would think many `[]` and `{}` are meant to be mutated, so it seems frozen Array/Hash literals them would rather be the exception than the norm (which is less clear for Strings, so I think there the magic comment makes sense).

I thought the same thing, but I'm not 100% convinced.  Lots of code in Rails (as well as our application at work) is merging some kind of "default hash" like:

~~~ ruby
def method(some_hash)
  some_hash = { :defaults => 'thing' }.merge(some_hash)
end
~~~

I'll try to get some numbers on this though.  :D



----------------------------------------
Feature #15393: Add compilation flags to freeze Array and Hash literals
https://bugs.ruby-lang.org/issues/15393#change-75557

* 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: #<ISeq:<compiled>@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: #<ISeq:<compiled>@thing.rb:0 (0,0)-(0,24)> (catch: FALSE)
0000 putobject                    "a"
0002 putself
0003 opt_send_without_block       <callinfo!mid:some_method, argc:0, FCALL|VCALL|ARGS_SIMPLE>, <callcache>
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!

---Files--------------------------------
0001-Add-compile-options-for-freezing-hash-and-array-lite.patch (6.14 KB)


-- 
https://bugs.ruby-lang.org/

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