From: "ioquatix (Samuel Williams)" <noreply@...>
Date: 2021-10-21T08:58:13+00:00
Subject: [ruby-core:105720] [Ruby master Bug#18258] Ractor.shareable? can be slow and mutates internal object flags.

Issue #18258 has been updated by ioquatix (Samuel Williams).


I feel from a predictability POV, it would definitely be advantageous to set `RB_FL_SHAREABLE` in every case it's known ahead of time to avoid unexpected overheads. Even if `Ractor.shareable?` is not public interface, it's still used internally in many many places...

----------------------------------------
Bug #18258: Ractor.shareable? can be slow and mutates internal object flags.
https://bugs.ruby-lang.org/issues/18258#change-94220

* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ko1 (Koichi Sasada)
* ruby -v: 3.0.2
* Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
On my computer, even with a relatively small object graph,`Ractor.shareable?` can be quite slow (around 1-2ms). The following example creates an object graph with ~40k objects as an example, and on my computer takes around 20ms to execute `Ractor.shareable?`. Because the object cannot be marked as `RB_FL_SHAREABLE` because it contains mutable state, every time we check `Ractor.shareable?` it will perform the same object traversal which is the slow path.

``` ruby
require 'benchmark'

class Borked
	def freeze
	end
end

class Nested
	def initialize(count, top = true)
		if count > 0
			@nested = count.times.map{Nested.new(count - 1, false).freeze}.freeze
		end
		
		if top
			@borked = Borked.new
		end
	end
	
	attr :nested
	attr :borked
end

def test(n)
	puts "Creating nested object of size N=#{n}"
	nested = Nested.new(n).freeze
	shareable = false
	
	result = Benchmark.measure do
		shareable = Ractor.shareable?(nested)
	end

	pp result: result, shareable: shareable
end

test(8)
```

I propose we change `Ractor.shareable?` to only check `RB_FL_SHAREABLE` which gives (1) predictable and fast performance in every case and (2) avoids mutating internal object flags when performing what looks like a read-only operation.

I respect that one way of looking at `Ractor.shareable?` is as a cache for object state. But this kind of cache can lead to unpredictable performance.

As a result, something like `String#freeze` would not create objects that can be shared with Ractor. However, I believe we can mitigate this by tweaking `String#freeze` to also set `RB_FL_SHAREABLE` if possible. I believe we should apply this to more objects. It will lead to more predictable performance for Ruby.

Since there are few real-world examples of Ractor, it's hard to find real world example of the problem. However, I believe such an issue will prevent Ractor usage as even relatively small object graphs (~1000 objects) can cause 1-2ms of latency, and this particular operation does not release the GVL either which means it stalls the entire VM.

This issue came from discussion regarding https://bugs.ruby-lang.org/issues/18035 where we are considering using `RB_FL_SHAREABLE` as a flag for immutability. By fixing this issue, we make it easier to implement model for immutability because we don't need to introduce new flags and can instead reuse existing flags.



-- 
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>