Without this change, classes (including iclass) are allocated
as un-boxable classes after initializing user boxes (after starting
script evaluation). Under this situation, iclasses are created as
un-boxabled class when core modules are included by a class in the
root box, then it causes problems because it's in the root box but
it can't have multiple classexts.
This change makes it possible to allocate boxable classes even after
initializing user boxes. Classes create in the root box will be
boxable, and those can have 2 or more classexts.
Since singleton classes are created lazily, we need to make sure that
we lock around their creation. Unfortunately, that means we need to
lock around every shareable object's call to `singleton_class`,
including classes and modules.
Safe multi-ractor subclass list mutation
We need to lock around mutation and accesses of a class's subclasses
list. Unfortunately we also need to do this when creating singleton
classes, as the singleton class does need to go into `super`'s
subclasses list for CC invalidation purposes.
Found by wbcheck
It seems like here the classext was associated with the class, but it
already had Ruby objects attached.
rb_gc_writebarrier_remember works around that issue, but I suspect if we
enabled autocompaction the values copied into the classext before it was
attached could be broken.
This reverts commit 2998c8d6b99ec49925ebea42198b29c3e27b34a7.
We need to find a better way to fix this bug. Even with this refcount
change, errors were still being seen in CI. For now we need to remove
this failing test.
We don't decrement the super and module subclasses count for iclasses that
are having their classext replaced. This causes the reference count to be
incorrect and leak memory.
The following script demonstrates the memory leak:
module Foo
refine(Object) do
define_method(:<=) {}
end
end
class Bar
include Comparable
end
With RUBY_FREE_AT_EXIT and ASAN, we can see many memory leaks, including:
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x599f715adca2 in calloc (miniruby+0x64ca2)
#1 0x599f716bd779 in calloc1 gc/default/default.c:1495:12
#2 0x599f716d1370 in rb_gc_impl_calloc gc/default/default.c:8216:5
#3 0x599f716b8ab1 in ruby_xcalloc_body gc.c:5221:12
#4 0x599f716b269c in ruby_xcalloc gc.c:5215:34
#5 0x599f715eab23 in class_alloc0 class.c:790:22
#6 0x599f715e4bec in class_alloc class.c:836:12
#7 0x599f715e60c9 in module_new class.c:1693:17
#8 0x599f715e60a2 in rb_module_new class.c:1701:12
#9 0x599f715e6303 in rb_define_module class.c:1733:14
#10 0x599f715ebc5f in Init_Comparable compar.c:315:22
#11 0x599f716e35f5 in rb_call_inits inits.c:32:5
#12 0x599f7169cbfd in ruby_setup eval.c:88:9
#13 0x599f7169cdac in ruby_init eval.c💯17
#14 0x599f715b0fa9 in rb_main main.c:41:5
#15 0x599f715b0f59 in main main.c:62:12
#16 0x739b2f02a1c9 in __libc_start_call_main csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#17 0x739b2f02a28a in __libc_start_main csu/../csu/libc-start.c:360:3
#18 0x599f7157c424 in _start (miniruby+0x33424)
Classes/modules defined in a namespace are defined under ::Object
as usual (as without namespaces), and it'll be set into the const_tbl
of ::Object.
In namespaces, namespace objects' const_tbl is equal to the one of ::Object.
So constants of ::Object are just equal to constants of the namespace.
That means, top level classes/modules in a namespace can be referred
as namespace::KlassName without calling rb_define_class_under_id().
Calling the usual rb_iclass_classext_free() causes SEGV because
duplicating a newer classext of iclass had set the reference from superclass
to the newer classext, but calling rb_iclass_classext_free() deletes it.
to adopt strict shareable rule.
* (basically) shareable objects only refer shareable objects
* (exception) shareable objects can refere unshareable objects
but should not leak reference to unshareable objects to Ruby world
The st_insert in RCLASS_SET_NAMESPACE_CLASSEXT may overwrite an existing
rb_classext_t, causing it to leak memory. This commit changes it to use
st_update to free the existing one before overwriting it.
We duplicate the method table in rb_class_duplicate_classext, so we should
set RCLASSEXT_ICLASS_IS_ORIGIN and unset RCLASSEXT_ICLASS_ORIGIN_SHARED_MTBL
to signal that the iclass owns the method table and it should be freed.
remove_class_from_subclasses calls st_insert, which mallocs. Malloc is not
allowed in GC. This commit replaces the st_insert with an st_update since
we know that ns_id exists in the st_table.
The following script reproduces the crash:
require "tempfile"
Tempfile.create do |file|
ns = Namespace.new
ns.require(file)
end
* ZJIT: Add NoSingletonClass patch point
This patch point makes sure that when the object has a singleton class,
the JIT code is invalidated. As of now, this is only needed for C call
optimization.
In YJIT, the singleton class guard only applies to Array, Hash, and String.
But in ZJIT, we may optimize C calls from gems (e.g. `sqlite3`). So the
patch point needs to be applied to a broader range of classes.
* ZJIT: Only generate NoSingletonClass guard when the type can have singleton class
* ZJIT: Update or forget NoSingletonClass patch point when needed
to fix inconsistent and wrong current namespace detections.
This includes:
* Moving load_path and related things from rb_vm_t to rb_namespace_t to simplify
accessing those values via namespace (instead of accessing either vm or ns)
* Initializing root_namespace earlier and consolidate builtin_namespace into root_namespace
* Adding VM_FRAME_FLAG_NS_REQUIRE for checkpoints to detect a namespace to load/require files
* Removing implicit refinements in the root namespace which was used to determine
the namespace to be loaded (replaced by VM_FRAME_FLAG_NS_REQUIRE)
* Removing namespaces from rb_proc_t because its namespace can be identified by lexical context
* Starting to use ep[VM_ENV_DATA_INDEX_SPECVAL] to store the current namespace when
the frame type is MAGIC_TOP or MAGIC_CLASS (block handlers don't exist in this case)
Previously we had an assertion that the method table was only set on
young objects, and a comment stating that was how it needed to be used.
I think that confused the complexity of the write barriers that may be
needed here.
* Setting an empty M_TBL never needs a write barrier
* T_CLASS and T_MODULE should always fire a write barrier to newly added
methods
* T_ICLASS only needs a write barrier to methods when
RCLASSEXT_ICLASS_IS_ORIGIN(x) && !RCLASSEXT_ICLASS_ORIGIN_SHARED_MTBL(x)
We shouldn't assume that the object being young is sufficient, because
we also need write barriers for incremental marking and it's unreliable.
When creating a new origin in ensure_origin, we need to fire a write
barrier after RCLASS_WRITE_ORIGIN. rb_class_set_super allocates, so GC
could happen there, either incrementally marking or promoting the newly
allocated class, and only after RCLASS_WRITE_ORIGIN will origin mark
object in the M_TBL.
The `FL_FREEZE` flag is redundant with `SHAPE_ID_FL_FROZEN`, so
ideally it should be eliminated in favor of the later.
Doing so would eliminate the risk of desync between the two, but
also solve the problem of the frozen status being global in namespace
context (See Bug #21330).
Even when namespaces are enabled, only a few core classes created
during init will eventually be namespaced.
For these it's OK to allocate a 320B slot to hold the extra namespace
stuff.
But for any class created post init, we know we'll never need the
namespace and we can fit in a 160B slot.
This behave almost exactly as a T_OBJECT, the layout is entirely
compatible.
This aims to solve two problems.
First, it solves the problem of namspaced classes having
a single `shape_id`. Now each namespaced classext
has an object that can hold the namespace specific
shape.
Second, it open the door to later make class instance variable
writes atomics, hence be able to read class variables
without locking the VM.
In the future, in multi-ractor mode, we can do the write
on a copy of the `fields_obj` and then atomically swap it.
Considerations:
- Right now the `RClass` shape_id is always synchronized,
but with namespace we should likely mark classes that have
multiple namespace with a specific shape flag.
MAX_IV_COUNT is a hint which determines the size of variable width
allocation we should use for a given class. We don't need to scope this
by namespace, if we end up with larger builtin objects on some
namespaces that isn't a user-visible problem, just extra memory use.
Similarly variation_count is used to track if a given object has had too
many branches in shapes it has used, and to use too_complex when that
happens. That's also just a hint, so we can use the same value across
namespaces without it being visible to users.
Previously variation_count was being incremented (written to) on the
RCLASS_EXT_READABLE ext, which seems incorrect if we wanted it to be
different across namespaces
Previously we used a flag to set whether a module was uninitialized.
When checked whether a class was initialized, we first had to check that
it had a non-zero superclass, as well as that it wasn't BasicObject.
With the advent of namespaces, RCLASS_SUPER is now an expensive
operation, and though we could just check for the prime superclass, we
might as well take this opportunity to use a flag so that we can perform
the initialized check with as few instructions as possible.
It's possible in the future that we could prevent uninitialized classes
from being available to the user, but currently there are a few ways to
do that.
If any other flags were passed other than type they were ignored, so we
might as well be more explicit that that's all this accepts. This also
fixes the incorrect (internal) documentation.
It also turns out type is always known in the caller, so I made it
explicit in the two places additional flags were being passed.
This makes `RBobject` `4B` larger on 32 bit systems
but simplifies the implementation a lot.
[Feature #21353]
Co-authored-by: Jean Boussier <byroot@ruby-lang.org>
Superclasses can't be modified by user code, so do not need namespace
indirection. For example Object.superclass is always BasicObject, no
matter what modules are included onto it.
`ext` is newly allocated so it shouldn't need an assertion. The class
ext (which is always from the module) that we're passing to
`class_duplicate_iclass_classext` could legitimately have instance
variables on it. We just want to avoid copying them.
The assertion was making this crash:
```
$ RUBY_NAMESPACE=1 ./miniruby -e1
```
