When implementing native types with theTypedData API, You have to define an allocator function.
That function receive the class to allocate and is supposed to return a new instance.

/** * This is  the type of  functions that ruby calls  when trying to  allocate an * object.  It is  sometimes necessary to allocate extra memory  regions for an * object.  When you define a class that uses ::RTypedData, it is typically the * case.  On  such situations  define a function  of this type  and pass  it to * rb_define_alloc_func(). * * @param[in]  klass  The class that this function is registered. * @return     A newly allocated instance of `klass`. */typedefVALUE(*rb_alloc_func_t)(VALUEklass);

Current API shortcomings¶

There are a few limitations with the current API.

Hard to disallow.allocate without breaking#dup and#clone.¶

First, it is frequent for extensions to want to disableClass#allocate for their native types viarb_undef_alloc_func, as very often allowing uninitialized object would lead to bugs.

The problem withrb_undef_alloc_func is that the alloc func is also used internally bydup andclone, so most types that undefine the allocator also prevent object copy without necessarily realizing it.

If you want to both disableClass#allocate yet still allow copying, you need to entirely implement the#dup and#clone methods, which is non-trivial and very few types do. One notable exception isBinding, which has to implement these two methods:https://github.com/ruby/ruby/blob/bea48adbcacc29cce9536977e15ceba0d65c8a02/proc.c#L301-L326

This works for Ruby code, however it doesn't work with C-levelrb_obj_dup(VALUE), as used by the Ractor logic to copy objects across ractors.
In the case ofBinding we probably wouldn't allow it anyway, but for other types it may be a problem.

Can't support objects of variable width¶

When duping or cloning an object of variable width, you need access to the original object to be able to allocate the right slot size.

An example of that isThread::Backtrace objects, as evidenced by [Bug#21818].

To support sending exception objects across ractors, we'd need to makerb_obj_dup() work forThread::Backtrace, but to correctly duplicate a backtrace, the allocator needs to know the size.

Proposed new API¶

I'd like to propose a new API for defining allocators:

typedefVALUE(*rb_copy_alloc_func_t)(VALUEklass,VALUEother);

In addition to the class to allocate, the function also receives the instance to copy.
When called byClass#allocate, theother argument is set toQundef. Example usage:

staticVALUEbacktrace_alloc(VALUEklass,VALUEother){rb_backtrace_t*bt;if(UNDEF_P(other)){// Regular allocreturnTypedData_Make_Struct(klass,rb_backtrace_t,&backtrace_data_type,bt);}else{// Copyrb_backtrace_t*other_bt;TypedData_Get_Struct(other,rb_backtrace_t,&backtrace_data_type,other_bt);VALUEself=backtrace_alloc_capa(other_bt->backtrace_size,&bt);bt->backtrace_size=other_bt->backtrace_size;MEMCPY(bt->backtrace,other_bt->backtrace,rb_backtrace_location_t,other_bt->backtrace_size);returnself;}}

Backward compatibility¶

Older-style allocator can keep being supported as long as we wish.

The one backward potential compatibility concern is third party code that callsrb_alloc_func_t rb_get_alloc_func(VALUE klass);.
As its documentation suggest, there's not much valid use case for it, but regardless we can keep supporting it by returning
a "jump function". Seecopy_allocator_adapter:https://github.com/ruby/ruby/pull/15795/changes#diff-884a5a8a369ef1b4c7597e00aa65974cec8c5f54f25f03ad5d24848f64892869R1640-R1653

Opportunity for more changes?¶

I was discussing this new interface with@ko1 (Koichi Sasada) and it appears that the current allocator interface may also be a limitation for Ractors and Ractor local GC. i.e. it might be useful to let the allocator function know that we're copying from one Ractor to another.

But I know to little about Ractor local GC to make a proposition here, so I will let@ko1 (Koichi Sasada) make suggestions.

Implementation¶

I implemented this idea inhttps://github.com/ruby/ruby/pull/15795, to solve [Bug#21818].
It could remain a purely private API, but I think it would make sense to expose it.