[#90399] [Ruby trunk Feature#14813] [PATCH] gc.c: make gc_enter+gc_exit pairs dtrace probes, too — ko1@...
Issue #14813 has been updated by ko1 (Koichi Sasada).
3 messages
2018/12/10
[#90417] [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD — naruse@...
Issue #15398 has been reported by naruse (Yui NARUSE).
4 messages
2018/12/11
[#90423] Re: [Ruby trunk Bug#15398] TestThread#test_signal_at_join fails on FreeBSD
— Eric Wong <normalperson@...>
2018/12/11
[email protected] wrote:
[#90519] Spoofing warnings for mail from bugs.ruby-lang.org — Charles Oliver Nutter <headius@...>
I'm getting a spoofing warning for emails sent from bugs.ruby-lang.org when
4 messages
2018/12/13
[#90522] Re: Spoofing warnings for mail from bugs.ruby-lang.org
— Eric Wong <normalperson@...>
2018/12/13
Charles Oliver Nutter <[email protected]> wrote:
[#90533] [Ruby trunk Feature#15413] unmarkable C stack (3rd stack) — normalperson@...
Issue #15413 has been reported by normalperson (Eric Wong).
3 messages
2018/12/14
[#90581] [Ruby trunk Bug#15424] Ruby 2.6.0rc1 & 2.6.0rc2 mutex exception — mat999@...
Issue #15424 has been reported by splitice (Mathew Heard).
3 messages
2018/12/17
[#90595] [Ruby trunk Bug#15430] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been reported by hsbt (Hiroshi SHIBATA).
3 messages
2018/12/18
[#90614] [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI — hsbt@...
Issue #15430 has been updated by hsbt (Hiroshi SHIBATA).
4 messages
2018/12/19
[#90630] Re: [Ruby trunk Bug#15430][Assigned] test_fork_while_parent_locked is failing status on Ruby CI
— Eric Wong <normalperson@...>
2018/12/20
> It still exists. https://rubyci.org/logs/rubyci.s3.amazonaws.com/centos7/ruby-trunk/log/20181218T230003Z.fail.html.gz
[#90820] Re: [ruby-cvs:73697] k0kubun:r66593 (trunk): accept_nonblock_spec.rb: skip spurious failure — Eric Wong <normalperson@...>
[email protected] wrote:
3 messages
2018/12/30
[ruby-core:90549] [Ruby trunk Feature#15393] Add compilation flags to freeze Array and Hash literals
From:
eregontp@...
Date:
2018-12-15 13:27:04 UTC
List:
ruby-core #90549
Issue #15393 has been updated by Eregon (Benoit Daloze).
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)
```
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.
----------------------------------------
Feature #15393: Add compilation flags to freeze Array and Hash literals
https://bugs.ruby-lang.org/issues/15393#change-75698
* 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:[email protected]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>