Shibuya.Pm#10 Lt Wakapon

SV アリーナ概要話者： wakapon

アジェンダ

なぜ今回，話者になったのか

Perl 処理系のヒープメモリプールについて

時間があれば ExtraStage

まずは自己紹介から

こんなブログを書いている中の人

こんなブログをやっています

まだ本題にいきません

引き続き

今回話者になったいきさつ

ひとことで表すと

ゆっくりしすぎた

ゆっくり

ゆっくりしすぎたこの結果

21:30 ころにはすでに締切り

だいたい 2 時間くらい？

わらにすがってみた

そんな折，

残り 1 つの LT 枠で何か話しませんか？ from 竹迫さん

ktkr ！でもなに話そう ...

そうだ，ブログに書いたあれにしよう

処理系のヒープメモリプール管理

処理系内部のメモリ管理ってどうなってるの？

必要になったら毎回 malloc ？

それとも独自の管理機構を持ってるの？

本発表内容の位置づけ

SvREFCNT よりも下の階層

リファレンスカウンタ方式のその先

いろいろな AP Web AP 　フレームワーク神々しい CPAN モジュール群 XS モジュール Perl API 構文解析 / 字句解析 OP ツリー生成インタプリタヒープメモリプール管理 libXXX

いろいろな AP Web AP 　フレームワーク神々しい CPAN モジュール群 XS モジュール Perl API 構文解析 / 字句解析 OP ツリー生成インタプリタヒープメモリプール管理 libXXX .pl / .cgi .pm .xs / .h .c / .h .c / .h / .asm 熱い領域暗黒面別世界

いろいろな AP Web AP 　フレームワーク神々しい CPAN モジュール群 XS モジュール Perl API 構文解析 / 字句解析 OP ツリー生成インタプリタヒープメモリプール管理 libXXX 今回のテーマはここ

ぜんぜん LT に持って来いな内容じゃあないですね分かります

ということで

残り 3 分半で本題にいきます

Perl に関する周知の事実

メモリをもりもり食う

そもそもメモリって具体的になぁに？

1 プロセスの仮想アドレス空間 (U) コード (.text) データ (.data .bss) ヒープスタック伸伸 ← ここ！ 0x00000000 0xC0000000

ヒープメモリ

プログラム実行中に動的確保

空きが無くなってきたらおっきさせる

ヒープ内部はライブラリで管理

malloc/free 関数でヒープを利用

Perl プログラム中 malloc の利用例

よくある 1 ステートメント my $hoge = 'foo';

レキシカル変数の管理表

変数名

文字列を格納するスカラ変数

文字列の実体

代入 OP

他にもいっぱい

毎回 malloc していると malloc がボトルネック

これに対する Perl 処理系の solution

ある程度まとめて一括して malloc

libc ではなく処理系自身でヒープ管理

利点

ライブラリコールのオーバヘッド削減

ヒープ領域拡張のためのシステムコール回数の削減

わかりやすい？例一軒家 × 賃貸マンション

いちいち立て直す家 = 一軒家

のではなく

中の人 / 荷物だけ入れ替わる，再利用 = 賃貸

かつ

一定人数の住居スペースをいっぺんに確保 = マンション

1 度構築したスペースを再利用することで

入れ物の再構築分のコスト減

コスト新規建築 >> 引越し

ここで #9 の復習 begin

SV

SV = スカラ変数すべての型の基底クラス

スカラ変数以外の型 ( 配列 / ハッシュ / サブルーチン ...) ↓ SV のサブクラス

出典： http://www.perl.org/tpc/1998/Perl_Language_and_Modules/Perl%20Illustrated/

SV = SV ヘッド (struct sv) + SV ボディ (struct xpvFOO)

SV はヘッドとボディからの 2 部構成

SV のサブクラス ↓ SV ヘッドの構造は共通 SV ボディの部分は異なる

復習おわり end

閑話休題

ある程度まとめて一括して malloc

libc ではなく処理系自身でヒープメモリ管理

1 に対する内部構造

アリーナ (arena) 1 回の malloc で取得するヒープメモリの単位 = 管理情報 + 生メモリチャンク

SV ヘッド， SV ボディごとにアリーナを用意

2 に対する内部構造

処理系で回収したメモリは全部 free しない

いつでも再利用可能な状態で処理系内部にためこんでおく

今回は SV ヘッドのアリーナだけ

SV ボディは SV ヘッドとほとんど同じ

まずは 1 つ目アリーナの構造から

SV ヘッドのアリーナの最小構成単位 = SV(struct sv)

SV ヘッドのアリーナの構造 ↓ SV ヘッドの線形リスト

SVヘッドのアリーナ 1 アリーナ・・・ SV SV SV SV 利用不可利用可

1 アリーナ処理系の SV ヘッダ malloc の単位 (※ 発表上の造語 )

1 アリーナ中の SV に空きが無くなると ...

ふえるつながる

ふえてつながったアリーナ群 = アリーナリスト

SVヘッドのアリーナリスト・・・ SV SV SV SV 利用不可利用可使用済み 1アリーナ新規1アリーナ・・・ SV SV SV SV

続いて 2 つ目未使用 SV の管理構造

アリーナ中の未使用 SV の管理 ↓ 未使用 SV ヘッダリスト

新たに SV ヘッドが要求された場合 ↓ 未使用 SV ヘッドを返す

それとは逆に

プログラム内でメモリ回収が行われた場合

構造体の内容を初期化後 ↓ 未使用リストへ

アリーナリストと未使用リスト・・・ SV SV SV SV ・・・ SV SV SV SV 利用不可利用可使用済み 1アリーナ 1アリーナ未使用リストアリーナリスト・・・

5.10.0 における実装

SV ヘッドに関連する変数

PL_sv_root SV ヘッドの未使用リストのルート

PL_sv_arenaroot SV ヘッドアリーナリストのルート

PL_sv_root と PL_sv_arena ・・・ SV SV SV SV ・・・ SV SV SV SV アリーナアリーナ PL_sv_root PL_sv_arena sv_any sv_any sv_any sv_any sv_refcnt 個利用不可利用可使用済み・・・

アリーナ操作の内部API (抜粋)

new_SV 未使用リストから SV の取得

more_SV アリーナの新規作成とアリーナリストへ接続

del_SV 構造体を初期化後，未使用リストへ接続

SvREFCNT_dec マクロと未使用 SV リストの関係

リファレンスカウンタを減算後，カウンタ値が 0 だった場合 ↓ 該当 SV を PL_sv_root の末尾に接続

アリーナリストの解放のタイミング

アリーナリストの解放インタプリタ終了時 = perl_destruct

perl_destruct

SV ボディの解放

SV ヘッダの解放

SV ボディアリーナの解放

SV ヘッダアリーナの解放

SV ボディについてもちょっとだけ

SV ボディに関連する変数

PL_body_roots[ SVt_LAST ] SV ボディの未使用リストルートの配列配列の index = SV type

PL_body_arenas SV ボディディスクリプタのリストのルートディスクリプタ内部の set にアリーナ

PL_body_roots と PL_body_arenas PL_body_arenas PL_body_roots[2] PL_body_roots[11] アリーナ集合 xpviv xpviv ・・・ xpvav xpvav ・・・アリーナ集合 xpvcv xpvcv ・・・ xpvav xpvav ・・・利用可使用済み・・・ PL_body_roots[13] PL_body_roots[0] ・・・・・・ arena_desc arena_desc

アリーナ操作の内部API (抜粋)