Any comment on officially supporting this as part of the C API?
diff --git a/README.EXT b/README.EXT
index d66d6c5..dded850 100644
--- a/README.EXT
+++ b/README.EXT
@@ -1176,6 +1176,12 @@ void rb_global_variable(VALUE *var)
Tells GC to protect these variables.
+void rb_gc_register_mark_object(VALUE val)
+
+ Tells GC to protect the object referenced by val. This requires less
+ memory to track than rb_global_variable, but may only be used if the C
+ variable never changes.
+
== Constant Definition
void rb_define_const(VALUE klass, const char *name, VALUE val) ::
+void rb_gc_register_mark_object(VALUE val)
+
+ Tells GC to protect the object referenced by val. This requires less
+ memory to track than rb_global_variable, but may only be used if the C
+ variable never changes.
+
How about that?
Tells GC to protect the object referenced by val.
Another things are implementation details.
And I'm not sure the following sentence is needed.
but may only be used if the C
variable never changes.
I think it may assume global variables. But this API is independent from
C's global variables. I think this comment may be for rb_global_variable users, but it is different API.
PS.
For our MVM development, we can not support rb_global_variable(). So I
want to make it obsolete.
This is why I introduce rb_gc_register_mark_object(). But not yet.
+void rb_gc_register_mark_object(VALUE val)
+
+ Tells GC to protect the object referenced by val. This requires less
+ memory to track than rb_global_variable, but may only be used if the C
+ variable never changes.
+
How about that?
Tells GC to protect the object referenced by val.
Another things are implementation details.
And I'm not sure the following sentence is needed.
but may only be used if the C
variable never changes.
I think it may assume global variables. But this API is independent from
C's global variables. I think this comment may be for rb_global_variable users, but it is different API.
I think it is important to tell users how it is different from rb_global_variable and when it is OK or not OK to use. So I think
the implementation details/difference from rb_global_variable is
important to prevent misuse.
May we consider this part of the supported C API?
PS.
For our MVM development, we can not support rb_global_variable(). So I
want to make it obsolete.
This is why I introduce rb_gc_register_mark_object(). But not yet.
Is MVM still happening? I haven't heard about it in a long time.
If so, we should move fstring and symbol table into the vm struct.
I tried making rb_gc_register_address work transparently but wasn't able
to measure any difference with unicorn. unicorn uses a few global
const strings for common HTTP headers, but maybe not enough to matter
for this patch.
This patch is probably pointless, but in case somebody else wants to try
and show it makes a difference, it is here: