We needed to preserve the original method name somewhere. We kept it in
the `env` structure pointed from aliased methods. #1457 and #1531 tried
to address this issue. But this patch is more memory efficient.
Limitation: this fix does not support `super` from methods defined by
`define_method`. This limitation may be addressed in the future, but
it's low priority.
The binary sizes (gems are only `mruby-bin-mruby`) are reduced slightly in
my environment than before the introduction of new specifiers/modifiers
(5116789a) with this change.
------------+-------------------+-------------------+--------
BINARY | BEFORE (5116789a) | AFTER (This PR) | RATIO
------------+-------------------+-------------------+--------
mruby | 593416 bytes | 593208 bytes | -0.04%
libmruby.a | 769048 bytes | 767264 bytes | -0.23%
------------+-------------------+-------------------+--------
BTW, I accidentally changed `tasks/toolchains/visualcpp.rake` at #4613,
so I put it back.
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