Now the method tables (in classes/modules and caches) keeps C function
pointers without wrapping in `struct RProc` objects. For the sake of
portability, `mrb_method_t` is represented by the struct and union, but
if the most significant bit of the pointer is not used by the platform,
`mrb_method_t` should be packed in `uintptr_t` to reduce memory usage.
`MRB_METHOD_TABLE_INLINE` is turned on by default for linux.
Instead of `irep` links, we added a `upper` link to `struct RProc`.
To make a space for the `upper` link, we moved `target_class` reference.
If a `Proc` does not have `env`, `target_class` is saved in an `union`
shared with `env` (if a `Proc` has env, you can tell it by `MRB_PROC_ENV_P()).
Otherwise `target_class` is referenced from `env->c`. We removed links
in `env` as well.
This change removes 2 members from `mrb_irep` struct, thus saving 2
words per method/proc/block. This also fixes potential memory leaks
due to the circular references caused by a link from `mrb_irep`.
ref #3215
If a function (such as mrb_read_irep_file()) is declared without MRB_API
in header file (such as include/mruby/dump.h), implementation of the
function in source file (such as src/load.c) should also defined without
MRB_API.
If MRB_API is mismatch, Visual C++ reports link error with C2375 error
code: https://msdn.microsoft.com/en-us/library/5k6kw95a.aspx
mrb_proc_new_cfunc_with_env() allocates RProc with RProc::env as NULL
then allocates REnv and sets it to RProc::env of the allocated RProc. If
incremental GC is ran before "allocates REnv and sets it to RProc::env
of the allocated RProc", the allocated RProc's GC status is
"marked" (Black) and the allocated REnv's GC status is
"unmarked" (White). The next incremental GC sweeps the allocated REnv
without re-marking the allocated RProc. Because the RProc is Black and
the REnv is White.
We need to implement write barrier for the case.
We can force to cause the above situation by the following patch:
diff --git a/src/proc.c b/src/proc.c
index f98998f..4f4e25c 100644
--- a/src/proc.c
+++ b/src/proc.c
@@ -92,6 +92,7 @@ mrb_proc_new_cfunc_with_env(mrb_state *mrb, mrb_func_t func, mrb_int argc, const
struct REnv *e;
int i;
+ mrb_incremental_gc(mrb);
p->env = e = env_new(mrb, argc);
MRB_ENV_UNSHARE_STACK(e);
e->stack = (mrb_value*)mrb_malloc(mrb, sizeof(mrb_value) * argc);
With this patch, "rake test" causes segmentation fault.
From the CRuby 2.2.2 Proc#arity documentation:
If the block has optional arguments, returns -n-1, where n is the number
of mandatory arguments, with the exception for blocks that are not
lambdas and have only a finite number of optional arguments; in this
latter case, returns n.
KOBAYASHI Shuji