Add the ENV variable for Ractor.check_isolation

[hmcguire-shopify]

Run the block in a real non-main Ractor while preserving its closure and argument identities. Downgrade isolation violations to categorized warnings so applications can sweep worker-Ractor compatibility without stopping at the first failure.

Support an exclusive scheduler mode for race-free checks and cover the isolation gates, fast paths, messaging, and thread inheritance.

[hmcguire-shopify]

Sol's Review

 ### 1. Cross-objspace mutation still crashes the VM

 Severity: CRITICAL
 Location: thread.c:628-653, thread.c:963-972

 The check Ractor runs a caller-owned closure in a separate objspace. Writing an object allocated by the check
 Ractor into a caller-owned container creates an edge neither local GC can trace safely.

 Confirmed reproducer:

 ```ruby
   outer = []

   Ractor.check_isolation do
     100_000.times { outer << Object.new }
     GC.start
   end
 ```

 This aborts with try to mark T_NONE object and then segfaults, including under RUBY_RACTOR_EXCLUSIVE=1.

 The same ownership problem applies if the caller waiting on .value is interrupted: the caller-owned Proc and
 arguments may lose their owner-side roots while the hidden Ractor continues. I reproduced an abort after killing
 the waiting Thread, forcing GC, and then resuming the check Ractor.

 Required fix: Introduce an explicit cross-objspace ownership/rooting model, or redesign the special Ractor so
 arbitrary by-reference mutation cannot create these edges. Scheduler serialization alone cannot solve GC
 ownership.

 ### 2. By-reference messages still contain dangling pointers

 Severity: CRITICAL
 Location: ractor_sync.c:1071-1084

 The patch puts arbitrary unshareable objects into basket_type_ref, whose existing lifetime assumptions apply to
 shareable objects. Once queued in another Ractor, no owner-side pin keeps the payload alive.

 Sending a child-created Hash to a main-owned port, dropping the local reference, and forcing GC reliably aborts
 the VM—even in exclusive mode.

 Required fix: Preserve normal copy semantics, or introduce a dedicated borrowed-message representation that pins
 the payload in its owner’s objspace until dequeue or queue destruction.

 ### 3. Exclusive mode does not cover dedicated native threads

 Severity: HIGH
 Location: thread_sched.c:1796-1838

 max_cpu = 1 limits shared native threads. A thread promoted through rb_thread_lock_native_thread leaves that
 count, allowing a replacement shared thread to execute while the dedicated thread continues.

 The documentation now discloses this limitation, but it means the mode still cannot provide the safety guarantee
 needed for arbitrary by-reference execution.

 Required fix: Add a VM-wide Ruby-execution permit honored by both shared and dedicated native threads, with a
 native-thread regression test.

 ### 4. Warning traffic remains unbounded

 Severity: MEDIUM
 Location: ractor.c:4050-4068, vm_insnhelper.c:1142-1148

 A hot offending access emits a synchronous warning on every iteration. A large sweep can generate enormous stderr
 traffic or exhaust memory in a custom Warning.warn collector.

 Recommended fix: Deduplicate by violation kind and call site, or impose a per-check warning budget followed by a
 suppressed-count summary.

[yaroslav-shopify]

Setting RUBY_RACTOR_ISOLATION puts every Ractor.new in the process into
isolation-checking mode. Violations that would normally
raise Ractor::IsolationError are reported as :ractor_isolation warnings and execution
continues, so one run collects every place the code is not yet Ractor-safe.

RUBY_RACTOR_ISOLATION=1 ruby app.rb
RUBY_RACTOR_ISOLATION=1 bundle exec rspec

There is no method to call anymore.

What the mode does

• Every Ractor.new becomes a check Ractor.
• Every isolation violation warns instead of raising.
• All Ractors run on one GVL, per ko1 requirement.
• Repeated warnings are deduplicated.

-e:1: warning: can not access global variable $g from non-main Ractor
RUBY_RACTOR_ISOLATION: 9999 repeated isolation warnings suppressed

More

GC is global in check mode. Check mode passes arguments, block values and messages between Ractors by reference, so a Ractor's heap can be reachable only from another Ractor's roots. Every collection is now promoted to a global cycle over all objspaces, and a dying Ractor skips its local retire GC and leaves its pages for the next global sweep. This closes review finding #2 (receiver holding a sender's object past the sender's GC) and the related "try to mark T_NONE" crash from finding #1. Two regression tests cover both directions.

RUBY_RACTOR_ISOLATION=2 reports every hit. Level 1 keeps the per-site dedup and the exit summary for reading stderr by eye. Level 2 skips the dedup and the summary so a Warning.warn override or sort | uniq -c can build its own counts and record where each warning was first seen.

Grouping is keyed on the app site. The outer-variable Proc warning and the by-reference copy warning bypassed the dedup and reported <internal:ractor> as their location. All warnings now go through one emitter keyed on (message, nearest non-internal Ruby frame), so Ractor.new and port << obj report the caller's line and dedup per call site.

Example: three workers, each capturing an outer variable and sending five unshareable arrays.

x = [1]
port = Ractor::Port.new
3.times { Ractor.new(port) { |pt| 5.times { pt << [x] } }.value }

Level 1 groups the 18 hits into 2 lines:

$ RUBY_RACTOR_ISOLATION=1 ruby -W:no-experimental app.rb
app.rb:3: warning: can not isolate a Proc because it accesses outer variables (x).
app.rb:3: warning: can not copy an unshareable Array across Ractors; passing by reference under RUBY_RACTOR_ISOLATION
RUBY_RACTOR_ISOLATION: 16 repeated isolation warnings suppressed

Level 2 leaves the grouping to the consumer:

$ RUBY_RACTOR_ISOLATION=2 ruby -W:no-experimental app.rb 2>&1 | sort | uniq -c
  15 app.rb:3: warning: can not copy an unshareable Array across Ractors; passing by reference under RUBY_RACTOR_ISOLATION
   3 app.rb:3: warning: can not isolate a Proc because it accesses outer variables (x).

[luke-gruber]

Things look very good in general 👍

One thing I noticed was that GC.verify_internal_consistency is broken:

p Ractor.new { GC.verify_internal_consistency; :ok }.value
=begin
$ RUBY_RACTOR_ISOLATION=1 ./ruby -W0 verify_iso.rb
check_children_i: containment violation: unshareable VM/thread (objspace 0x94b0b1000) -> foreign unshareable proc (objspace 0x106976b40)
check_children_i: containment violation: unshareable fiber (objspace 0x94b0b1000) -> foreign unshareable T_IMEMO (objspace 0x106976b40)
root_scope_check_i: root category "ractor" names a foreign unshareable without a shref record: proc (owner 0x106976b40, self 0x94b0b1000)
-e:1: [BUG] gc_verify_internal_consistency: found internal inconsistency.
...
-e:1: [BUG] Segmentation fault at 0xfffffffffffffff8
=end

You just need to skip these checks in check isolation mode.

[luke-gruber]

I'm guessing this is defeated for any isolation error that shows the object's address. Is that why they try to avoid that by showing the class name? Do all the messages do this or only some? Either way, seems okay.

[yaroslav-shopify]

@luke-gruber thanks! Will do changes.