Namespace management using control frame #13454

tagomoris · 2025-05-28T00:18:03Z

This change is to update the namespace management. The main purpose is to fix bugs in corner cases to determine the current namespaces. I expect that this fix can solve bugs/problems to run RubyGems/Bundler with namespaces.

Core changes are:

Determine the current namespace by the local context (VM_CF_LEP or VM_EP_RUBY_LEP) basically
Stop using stacks for the namespace management
Start using control frames (especially cfp->ep[VM_ENV_DATA_INDEX_SPECVAL]) to store the namespace of the frame
- This is valid only when the frame type is VM_FRAME_MAGIC_TOP or VM_FRAME_MAGIC_CLASS
- Those frame types don't have block handlers (block handlers are stored in specval for other frame types)
Remove vm->load_path and other values, then start referring the root namespace (and its load_path and other fields) for simplicity
Stop using refinements to determine the loading namespace by setting VM_FRAME_FLAG_NS_REQUIRE

TODO:

Delete the unused code about the current namespace management in namespace.c
Define singleton methods on top_self under namespaces (#to_s and #inspect)
Implement freeing rb_namespace_t (especially loading_table_entry)
Update namespace_entry_memsize
Implement global variable handling based on root/main namespaces
Check vm_set_main_stack(ec, iseq); // TODO: not need to set the namespace?

Add tests about:

Basic namespace behavior
Current namespace management under CFUNC calls
Global variables in main/user namespaces

namespace.c

launchable-app · 2025-06-15T09:45:35Z

❌ Tests Failed

✖️no tests failed ✔️62282 tests passed(2 flakes)

…al contexts 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)

Calling rb_current_namespace() in rb_namespace_current() means to show the definition namespace of Namespace.current itself (it's the root always) but the users' expectation is to show the namespace of the place where the Namespace.current is called.

See 8b5ac5a

…and if needed

* checking all control frames (instead of filtering by VM_FRAME_RUBYFRAME_P) because VM_FRAME_FLAG_NS_REQUIRE is set on non-rubyframe * skip frames of CFUNC in the root namespace for Kernel#require (etc) to avoid detecting the root namespace of those frames wrongly

* The current namespace should be based on the Ruby-level location (file, line no in .rb) and we can get it by LEP(ep) basically (VM_ENV_FLAG_LOCAL flag is set) * But the control frame with VM_FRAME_MAGIC_CFUNC is also a LOCAL frame because it's a visible Ruby-level frame without block handlers * So, for the namespace detection, LEP(ep) is not enough and we need to skip CFUNC frames to fetch the caller of such frames

…/pop With this change, the argument code of Namespace#eval cannot refer local variables around the calling line, but it should not be able to refer these values. The code is evaluated in the receiver namespace, independently from the local context.

…namespace

tagomoris · 2025-08-12T01:59:44Z

vm.c

+        /* Never set black_handler for VM_FRAME_MAGIC_TOP or VM_FRAME_MAGIC_CLASS
+         * and the specval is used for namespace (rb_namespace_t) in these case
+         */
+        return VM_BLOCK_HANDLER_NONE;


For the anchor in the discussion: how to handle SPECVAL

k0kubun · 2025-08-12T21:57:48Z

vm.c

@@ -118,7 +141,15 @@ PUREFUNC(static inline VALUE VM_CF_BLOCK_HANDLER(const rb_control_frame_t * cons
 static inline VALUE
 VM_CF_BLOCK_HANDLER(const rb_control_frame_t * const cfp)
 {
-    const VALUE *ep = VM_CF_LEP(cfp);
+    const VALUE *ep;
+    if (VM_ENV_NAMESPACED_P(cfp->ep)) {


I'm confused by the fact that VM_CF_BLOCK_HANDLER()'s implementation is different from GET_BLOCK_HANDLER()'s. GET_BLOCK_HANDLER() checks VM_ENV_NAMESPACED_P on GET_LEP() while VM_CF_BLOCK_HANDLER() checks cfp->ep instead of using VM_CF_LEP(cfp), which is the one actually queried later.

What allows them to be different? How is it safe for VM_CF_BLOCK_HANDLER() to not check the EP that has the specval to be queried?

This if-clause is a kind of early returrn because if VM_ENV_NAMESPACED_P(ep) is true, then VM_ENV_LOCAL_P(ep) is also true and ep == VM_CF_LEP(ep) (at least for now). VM_ENV_BLOCK_HANDLER(ep) also checks VM_ENV_NAMESPACED_P(ep), so GET_BLOCK_HANDLER() returns the same result anyway.

I agree that it's confusing. So, I'll try to update GET_BLOCK_HANDLER definition to VM_CF_BLOCK_HANDLER(GET_CFP()) and check if it will work correctly.

nobu reviewed May 28, 2025

View reviewed changes

namespace.c Outdated Show resolved Hide resolved

tagomoris force-pushed the namespace-using-control-frame branch from 9cb95e9 to b0193f3 Compare June 1, 2025 03:19

tagomoris force-pushed the namespace-using-control-frame branch from fd04acf to 88e1fad Compare June 14, 2025 04:52

tagomoris force-pushed the namespace-using-control-frame branch from 139ed12 to a5bbd18 Compare June 15, 2025 10:04

tagomoris mentioned this pull request Jun 17, 2025

Update vm->self location and mark it in vm.c for consistency #13630

Merged

tagomoris force-pushed the namespace-using-control-frame branch from a5bbd18 to 0ac3835 Compare June 17, 2025 14:02

tagomoris force-pushed the namespace-using-control-frame branch from 0ac3835 to 1e43ad1 Compare June 29, 2025 00:48

Satoshi Tagomori added 10 commits August 10, 2025 14:48

There is no longer needs to evict ivars thanks to fields

5a491bc

See 8b5ac5a

Fix wrong way to check an object is an instance of rb_cNamespace

d797d7b

Stop using ns->top_self here because it's set to th->top_self beforeh…

2c13376

…and if needed

Follow the usual naming rule for singleton methods

d7f757a

Define a debug method Kernel#dump_classext only when RUBY_DEBUG is set

d5876f1

tagomoris force-pushed the namespace-using-control-frame branch from 547c63f to 5b8d4ab Compare August 11, 2025 04:47

Satoshi Tagomori added 3 commits August 11, 2025 16:13

Add and fix dependencies

d87f8ab

Skip loading gem_prelude in wasm environment

6cea12a

Stop using C23 spec: initialization with an empty struct

b47a40b

tagomoris force-pushed the namespace-using-control-frame branch from 35514e5 to b47a40b Compare August 11, 2025 08:51

Satoshi Tagomori added 2 commits August 12, 2025 10:08

add VM_ENV_NAMESPACED_P to unify/simplify/correct when SPECVAL has a …

68503b8

…namespace

fix the wrong patch: 6cea12a

c1f3b1a

tagomoris commented Aug 12, 2025

View reviewed changes

Satoshi Tagomori added 2 commits August 12, 2025 11:34

localize rb_vm_t and minimize times of GET_VM() calls

a8f6eaa

delete unused code

b06465c

k0kubun reviewed Aug 12, 2025

View reviewed changes

YJIT: Check VM_ENV_NAMESPACED_P in gen_block_given

d129669

XrXr mentioned this pull request Aug 13, 2025

YJIT: Fix defined?(yield) and block_given? at top level #14208

Merged

1 task

writing

f931a7f

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Namespace management using control frame #13454

Namespace management using control frame #13454

tagomoris commented May 28, 2025 •

edited

Loading

Uh oh!

Uh oh!

launchable-app bot commented Jun 15, 2025 •

edited

Loading

Uh oh!

tagomoris Aug 12, 2025 •

edited

Loading

Uh oh!

k0kubun Aug 12, 2025

Uh oh!

tagomoris Aug 23, 2025 •

edited

Loading

Uh oh!

Uh oh!

Namespace management using control frame #13454

Are you sure you want to change the base?

Namespace management using control frame #13454

Conversation

tagomoris commented May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

launchable-app bot commented Jun 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❌ Tests Failed

Uh oh!

tagomoris Aug 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

k0kubun Aug 12, 2025

Choose a reason for hiding this comment

Uh oh!

tagomoris Aug 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

tagomoris commented May 28, 2025 •

edited

Loading

launchable-app bot commented Jun 15, 2025 •

edited

Loading

tagomoris Aug 12, 2025 •

edited

Loading

tagomoris Aug 23, 2025 •

edited

Loading