Issue #9278 has been updated by tmm1 (Aman Gupta).


>> It seems like it would be logical for the VM to automatically
>> freeze/dedup string literal keys in hash literals and hash lookups. Is
>> there a reason that can't be done?
>
> That's a goal: https://bugs.ruby-lang.org/issues/8998
> Just need the time/effort.

I implemented such an optimization for Hash#[]= in https://bugs.ruby-lang.org/issues/9188#note-8

A similar patch could be developed for the aref case, but I'm not sure if the perf improvement would be worth a specialized instruction. In fact, there's not really a performance improvement, but rather less pressure on the GC. That can be beneficial, but it can also be addressed by GC improvements.

As far as a immutable string magic comment, I'm still unconvinced. Perhaps if you show concrete gains in a large code-base like rails the case will be more compelling.
----------------------------------------
Feature #9278: Magic comment "immutable: string" makes "literal".freeze the default for that file
https://bugs.ruby-lang.org/issues/9278#change-43965

Author: colindkelley (Colin Kelley)
Status: Open
Priority: Normal
Assignee: 
Category: core
Target version: 2.1.0


Building on https://bugs.ruby-lang.org/issues/9042, this pull request adds the magic comment # -*- immutable: string -*- that implies .freeze on every string literal in the file. To get a mutable string in a file that starts with the magic comment, use String.new or ''.dup.

Here is a corresponding github pull request:

    https://github.com/ruby/ruby/pull/487

For more details, background, and rationale, please see this blog post:

    http://development.invoca.com/magic-comment-immutable-string-makes-ruby-2-1s-literal-freeze-optimization-the-default/


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