[PoC] Reduce copy of C string to symbol in class, module and method definition.

[take-cheeze]

Since this is too big and breaks compatibility will split after reviews.

Most changes are to replace C function using const char* to macro and add _id suffix to it.
Some C function needs to have symbol for FFIs I've moved it to mruby-symbol-ext mrbgem.

For checking the improment I've added a feature to see how many symbol is static.
It seems most symbol can be static on launched VM.

[matz]

Have you measured how much memory (or object allocation) this patch reduced?

[take-cheeze]

config; https://gist.github.com/take-cheeze/36097cacd58bce1dd6ca2f430ceb9edf
time -v results(first half is master and second half is the patch applied):
https://gist.github.com/take-cheeze/d36108f43615dc172229ae4be121b4cd

Minor page faults occur on malloc-ed memory so seems it is 30 pages less when applied.
Page size is 4096 so 4096 * 30 = 120k less malloc-ed memory usage.

[take-cheeze]

Modification for time -v : https://gist.github.com/take-cheeze/24853d07dc694a34f7e3da9a57f5966e
mrbtest creates many VMs with full-core so maybe should compare mrb_open.

[matz]

Page faults are inaccurate and 30 minor page faults are less than 1.5% of total faults.
Could you measure the allocation amount by direct number, by using valgrind, for example?

[take-cheeze]

valgrind doesn't work well with fmt_fp.c so instead I used address sanitizer's stat:
https://gist.github.com/take-cheeze/dd8a932e98f0193e67e3f0eac0049ba5
https://gist.github.com/take-cheeze/9714b1fda87d11dcd4262c14f90ec52b

(ASAN_OPTIONS env var atexit enabled. And removed full-core since it is noisy.)

malloc call is slightly less(10k decrease):

master:
  Stats: 13M malloced (3M for red zones) by 117681 calls
symbol_literals:
  Stats: 13M malloced (3M for red zones) by 107390 calls

mmap is less too(about 10 maps):

master:
Stats: 23M (23M-0M) mmaped; 374 maps, 0 unmaps
  mallocs by size class: 2:46204; 3:10197; 4:33281; 6:2466; 7:1854; 8:1285; 11:9876; 12:650; 13:221; 14:146; 15:4803; 16:34; 17:441; 18:114; 19:166; 20:95; 21:12; 22:66; 23:4500; 24:45; 25:58; 26:361; 27:48; 29:187; 30:178; 31:44; 32:44; 33:95; 34:47; 35:44; 37:48; 38:2; 47:68; 49:1; 

symbol_literals:
Stats: 22M (22M-0M) mmaped; 365 maps, 0 unmaps
  mallocs by size class: 2:36832; 3:9188; 4:33370; 6:2422; 7:1899; 8:1285; 11:9832; 12:606; 13:265; 14:190; 15:4803; 16:34; 17:441; 18:114; 19:166; 20:95; 21:12; 22:66; 23:4500; 24:45; 25:58; 26:361; 27:48; 29:187; 30:179; 31:44; 32:44; 33:95; 34:47; 35:44; 37:48; 38:2; 47:67; 49:1; 

[matz]

I have read the patch:

• mrb_funcall etc. may not take string literals.
• if MRB_USE_ETEXT_EDATA is effective on the platform, should it reduce as much memory as this patch?

[take-cheeze]

mrb_funcall etc. may not take string literals.

At least in the core mrbgems I only need to modify mruby-struct for the API changes.
And I think the API to use should be different with dynamic strings and static strings.
(If possible static lifetime of rust would be great.)

if MRB_USE_ETEXT_EDATA is effective on the platform, should it reduce as much memory as this patch?

In some environment for example

• changing linker scripts is difficult
• dynamic linked symbols

can't be used.
If things can be judged in compile time I prefer to judge it as much as possible.