This commit introduces memory prefetching to the `bsearch_idx` functions
in `src/class.c` and `src/variable.c` to improve performance.
A new macro `MRB_MEM_PREFETCH` is defined in `include/mruby/variable.h`
which uses `__builtin_prefetch` if available.
Co-authored-by: Gemini <gemini@google.com>
This commit optimizes instance variable lookups by replacing the
search algorithm with the same branch-free binary search recently
introduced for method lookups. This improves performance by
avoiding CPU branch mispredictions.
This commit corrects the placement of C-style block comments
for MRB_API functions in src/variable.c. Comments are now
placed directly before each function definition as per standard
documentation practices.
Preserve the original iv_tbl heap layout and allocation pattern, but
switch iv_put to maintain sorted keys and iv_get/iv_del to perform
binary search. This eliminates extra probing overhead, improves
read-heavy lookup performance for small tables, and incurs zero
additional allocations.
Calling `mrb_gc_unregistor()` from `mrb_data_type::dfree` caused a use-after-free deep inside `mrb_close()`.
The impetus to investigate was <https://github.com/mruby/mruby/pull/6342#pullrequestreview-2292747530>.
Currently, when `mrb_close()` is called, all objects are destroyed first.
The process is done heap page by heap page, and when all objects belonging to a heap page are destroyed, the heap page is released.
If the next heap page contains `RData` objects, the `mrb_gc_unregistor()` function may be called from the `mrb_data_type::dfree` function.
At this time, the `mrb_gc_unregistor()` function gets an array object from a Ruby global variable.
If the array object belongs to a freed heap page, use-after-free is established by referencing this array object.
About the fixes.
First of all, there is the fact that the `mrb_gv_get()` function returns `nil` if `mrb->globals` is `NULL`.
Therefore, before destroying all objects, free `mrb->globals` and set `mrb->globals` to `NULL` at the same time.
Now the `mrb_gv_get()` function will return `nil` to the calling `mrb_gc_unregistor()` function and `mrb_gc_unregistor()` will do nothing more.
ref. https://github.com/mruby/mruby/issues/4618
As #6359 pointed out, calling const_missing hook from E_XXX_ERROR (that
calls mrb_exc_get_id()) can be an attack vector. Since E_XXX_ERROR is
supposed to be a defined error class, we think that the situation where
it is undefined and the const_missing hook is called should be detected
as an error; fix#6359
By adding a fast-path where we ignore boxed types we can gain a pretty substantial speedup of mrb_iv_get, making it about 25% faster during a standard optcarrot benchmark run.
NOTE: It is just mrb_iv_get that is that much faster, the whole benchmark seems to be about 3-5% faster with word boxing.
This will be a partial merge of #5317 with the following changes.
- Remove `iclass->iv_c` since `iclass->iv_c` is equivalent to `iclass->c`.
- `class_iv_ptr()` returns a single pointer instead of a double pointer.
Previously, for example, it was possible to retrieve the `String` class as follows:
```console
% bin/mruby -e 'p Comparable::Enumerable::Errno::GC::Kernel::Math::ObjectSpace::String'
String
```
Note that this patch affects the API function `mrb_const_get()`.
`mrb_class_find_path` resolves a `char*` pointer to a class name string
by calling `mrb_class_name`. It then allocates a new string with
capacity 40 to copy that `char*` into.
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/variable.c#L1111-L1112
`mrb_class_name` resolves the class name via `class_name_str`, which
returns an `mrb_value` with type tag `MRB_TT_STRING` and backed by an
`RString*`. Then `mrb_class_name` extracts the `RSTRING_PTR`:
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/class.c#L2133-L2134
That `RString*`-backed `mrb_value` ultimately comes from `mrb_class_path`
which resolves the string from the symbol table:
https://github.com/mruby/mruby/blob/e04184185ab43b94980550e850d8813a415fa438/src/class.c#L2111
The allocation of the target `str` after resolving the class name
`mrb_value` and extracting its pointer is fragile and assumes the
`RString*` is "static". If the `RString*` is not static, the
interleaving of extracting the `RSTRING_PTR` followed by a subsequent
allocation might result in the class name `mrb_value` being garbage
collected, which will leave the extracted pointer invalid.
Fix this bad interleaving by allocating the destination string first
before taking a raw pointer to an `RString*`.
Internal functions can only be called from within the library.
Functions listed in `mruby/internal.h` can be called from:
* core (src/*.c)
* gems (mrbgems/**/*.c)
But not from the application linked with `libmruby`.
dearblue