LMS

glibcmallocは一度挫折したことがあるので、そこらへんの話が聞けたらいーかなー、ってことで行ってきた。
期待通り、そこらへんの内容で、非常に良かったです。

mallocのソースは読みにくいとか。


あー、あとソースの読みかたとかは記録に残すべきなのだろうか。
僕のソースの読みかたは、必要に迫られてというか、いや、迫られてるわけではないんだけど。
「勉強のためにソースを読むぜ!」っていうのはやったことないんだよなー。

「○○っていう機能だけパクれないか?」っていうのがまず主な動機で、そこから色々と。
この方法の利点は、「どのファイルから読み始めるか」の指針が決まるので、読み易い…って、それ、気分の問題なんじゃないのか?誰かにガイドラインを与えられないと行動できない日本人であります。


とりあえず、帰って調べるか。

  • やっぱり、メモリをOSに返すタイミングが…O(1)でできるか?
  • 返すアルゴリズムによっては、やっぱbrkよりmmap使ったほうが…brkだと領域が分断できない
  • 領域の分断を考慮しないのなら、若干簡単になる部分があるけど…それだと、arenaから割り当てるときに1MB超えたら…

つまり、OSにリソースを返すタイミングがどうなってるかなんだけど。OSにリソース返す部分はそれなりにしかやってないんだろうか。
GNUのプログラムは、末端部分の最適化(教科書では「やってはいけない」って書いてある最適化)は頭がおかしいほどにやってるというイメージがあるんだけど、brk使ってるあたりに妥協してるような印象を受けるんだよなー。だから、そこらへんの事情がどうなってるか。
領域分断したら、カーネルに優しくないとかありそうだけど。


あと、PROT_NONEの必要性。

プログラミング言語理論への招待

おおおーソフマップ行ったら売ってたよー保護。メイヤー先生ー!!(とか言いつつオブジェクト指向入門は読んでないのだけど)
昔図書館にあったので、読んだことあったんだけど、あのときは若かったので、全然何書いてるかわからんかったのだよなー。今の僕なら、わかるかと言われるとそれは謎だけど。


でも、こういう貴重な本は僕みたいな人間が保持してしまっていいのか?とか、そういう説もあるような。


絶版本交換会とかあったらどうだろうか。プレゼント交換みたいな感じで、みんなで絶版本もちよって、ぐるぐるまわすみたいなの。