Issue #22274 has been updated by headius (Charles Nutter). A clarification about JVM buffer behavior (as in JRuby):
So having a GC move the internal backing memory around is a non-starter IMHO.
There's nothing problematic with movable buffer memory as long as the VM reaches a safe point before passing that address to native code. This is what the JVM does for heap-backed ByteBuffer. ByteBuffer can also wrap a "direct" native memory pointer if the cost of the safepoint is a problem, in which case the new cost becomes copying bytes to and from native memory. JRuby's IO::Buffer wraps the ByteBuffer provided by the JVM and can work with either form. Regarding freezing and set* operations, there is precedent: a sliced String must copy on write the shared contents, dodging the "frozen source" issue. Those are probably not the semantics we want for sliced buffers, but it's worth pointing out how another construct handles this situation. As a suggestion for an alternative way to "freeze" only the extents of memory region backing a buffer, I'd suggest #pin as a name, indicating that the buffer's data pointer will now never move, resize, or realloc (but that region might can still be written to). On JVM this could be a hint to switch the buffer to a direct pointer. Given the number of open issues I also agree this needs more bake time to leave experimental status but I support removing the warning. FWIW the Java/JVM folks have separate concepts of "incubating" features (probably most similar to "experimental") and "preview" features, which might have future API changes but are close to stabilizing (e.g. within a release or two). ---------------------------------------- Feature #22274: Make `IO::Buffer` no longer experimental. https://bugs.ruby-lang.org/issues/22274#change-119428 * Author: ioquatix (Samuel Williams) * Status: Open * Assignee: ioquatix (Samuel Williams) ---------------------------------------- `IO::Buffer` was introduced in Ruby 3.1 by Feature #18020 as an experimental API. It provides an efficient buffer abstraction for fiber scheduler I/O, zero-copy operations, binary protocol implementations, and access from native extensions. Since then, the API has seen several Ruby releases of real-world use and substantial development. Ruby 4.1 now has cohesive semantics for buffer ownership and lifecycle, slicing, locking, string and file mappings, MemoryView integration, and single-transfer I/O operations. I propose making both the Ruby and public C interfaces of `IO::Buffer` non-experimental in Ruby 4.1. This would involve: * Removing the allocation-time experimental warning. * Removing the experimental status from the class documentation. * Removing `RB_IO_BUFFER_EXPERIMENTAL` from the public C header. * Removing warning suppression that is only required because `IO::Buffer` is experimental. * Updating NEWS to describe `IO::Buffer` as stable. `RUBY_IO_BUFFER_VERSION` would remain available for compile-time feature detection as the interface continues to evolve. Before stabilizing the interface, I would particularly appreciate feedback from JRuby and TruffleRuby maintainers. Related work: * Original proposal: https://bugs.ruby-lang.org/issues/18020 * CRuby implementation PR: https://github.com/ruby/ruby/pull/18486 * TruffleRuby implementation: https://github.com/truffleruby/truffleruby/pull/4248 * JRuby implementation: https://github.com/jruby/jruby/blob/master/core/src/main/java/org/jruby/Ruby... * JRuby file-mapping issue: https://github.com/jruby/jruby/issues/8714 -- https://bugs.ruby-lang.org/