**********************************************************************
セッションs3c
テーマ：mrubyの省メモリ化について考える
講師: まつもと ゆきひろ, 高橋 征義, 山根 ゆりえ
日時：8/31(金) 10:25-11:15
参加人数：約20人
**********************************************************************

■セッション内容
背景:
マイコン上でmruby動かしたい→省メモリ化必要

mrb_open()のなかでやっている初期化部分を最適化したい
従来Rubyとして考えていなかったのは、初期化と実行の区別が少ないから。

事前に決定している情報はROMに配置して、
実行時に使うRAM上の情報と切り替えて使う。
ROMに入れた情報
- ソースに埋め込まれているシンボルを検出して入れた
- メソッド表

今後やりたいこと
- RClass, irepをROMに入れたい
- （そもそも）RAMに置く情報を減らす

irepは現在進行形でROMにおける部分は置こうとしている、
RClassは入れられないのではないかと思っている

RClassのROM化:
クラスをfreezeしたことにすれば可能？？
→ 数10バイトのためにポインタを結局配置し
　　直したりするのでコスパが悪い
irepのスリム化:
デバッグのための情報を減らせるようにする？
→ mruby/cではRAMに乗せる前提だったのですでに最小化されており、
逆にROM化は難しい。mrubyの方ができる可能性はある。

その他に考えていること

バイトコード化:
1バイト目が命令の種別になる
オペランドは3つまで。
オペランドが3つある場合、各オペランドは1バイトのメモリを指している
256で収まらない場合はOP_EXTnというprefixをつけると16bitにできる、という拡張をしている。

khashのTree化:
mrubyは挿入順の線形探索だが、
mruby/cは2分探索できるようにソートしてあってO(n)で挿入できる


■質疑応答

質:
バイトコード化について、可変長オペランドは無理なのか。
まつもと >
現状は3つ、設計上も拡張するのは難しいかも


質:
ROMにあまりおいてないのはなぜ。
まつもと >
Rubyの言語的な性質であまり問題になってなかったから。
Ruby本来の指向が変わらないのであれば、
今後は改善していこうとしている。


質:
初期化時では、実行するときに、1回目の情報を再利用して、2回目は変更点と
かだけを動的にすれば少し早くなるのでは。
山根 >
mruby開発者としては、一番最初の初期化は時間かかっても大丈夫なのかな？
というところから、とりあえずRAM使うのを小さくするというための
取り組みだった
質 >
要求によるけど、1回目ならという許容が発生したりするかも。


質:
そもそもROM化する要求はどこからきてる？
まつもと >
ROMは潤沢でも、RAMは少なかったりする。
山根 >
安いマイコンだとしんどかったりして、動かなかった経験

質:
edge化して他のリッチなホストで動かすとかはだめなのか
まつもと >
そもそもmrubyの対象は組込みからすると結構リッチだったのだが、
それでもちょっと大きめのものだとメモリが足りません、ということがあり、
もっと小さくとかっていう要求が出てきた

質: Cのコンパイルでは、シンボルにread only,
書き換え可能, 初期値があるなどの属性がついてるけど、Rubyはどうなってるのか？
まつもと >
Rubyでもシンボルなどは書き変わらないので、その配置を工夫することはでき、そのpull requestが来てる


■まとめ
mrubyの省メモリ化をするために、現在行っている取り組みおよび今後の対応できる
可能性に関して発表が行われた。
その発表をもとにmrubyを実際に使っている参加者からも、
複数の質問や提案が行われ活発な議論となった。


以上。