不具合農場 地獄の大豊作不具合様は本日もすこやかなれば、本日も大豊作なり。 不具合様には不具合をお供えすべし。 今日もお供え物作ってますか? |
トップへ戻る ブログのトップへ戻る Word Press |
|
不具合道楽 地獄のフルコース不具合御飯 不具合味噌汁 不具合満漢全席 | ||
コンピューターのはらわた無修正大公開 | ||
不具合設計局キャンペーン中 |
2012-10-24 (Wed)
_ [日々の生活] 64bitアドレス空間
古典的なメモリー管理において、確保したメモリーの容量を変更したい場合、「新たにメモリーを確保し、前のメモリーの内容をコピーしてから、前のメモリーを解放する」という手順が一般的でした。これは容量変更の際には、希望するメモリー容量のおよそ2倍のメモリーを瞬間的に要求するという点や、メモリーの確保解放を繰り返すことで、アドレス空間が断片化していくという点が問題点として指摘されていました。
私はこの問題については無視を決め込んでいて、断片化しようがおかまいなしという感じです。
でまあ、64bitでの話です。64bitの場合、アドレス空間が非常に広いため、メモリー確保の際にはアドレス空間だけ大きく確保しておいて、必要になった分だけ実際のメモリーを割り当てる(メモリーページコミットする)ということが可能なんですね。これは別に32bitでも技術的には可能な話ですが、アドレス空間の広さを考えると、32bitではしんどい話です。
とまあ、こんなことをふと思いついて(というか、スタックなんかはとっくにこの方式なんですが)、「ひょっとしてうまい方法かも?」と思ったのですが、どうなのかなあ。64bit Windowsにおいてアプリケーションが使用できるアドレス空間は8TBなんだそうで、32bit Windowsの4096倍あります。一方、メモリーのページサイズについては相変わらず4KBなんだそうな。メモリーページごとにアクセス属性情報や物理メモリへのマッピング情報があるわけですが、私は昔、こういう情報はどこに格納されているのか不思議に思ったのでした。ためしに1ページごとにアクセス属性が異なるメモリー領域を作ってみて、この領域にアクセスしまくるプログラムを書いてみたのですが、速度の減少は見られなかったんですよね。
今調べてみたら、メモリーページのアクセス属性情報や物理メモリへのマッピング情報というのは、メインメモリーに格納されていて、CPUはこの情報をキャッシュしながら使っているらしいです。(TLBと呼ばれるシステムです)
ページサイズが4KBのままで、扱うメモリー容量が大幅に増えた場合、キャッシュの容量が不足してくることが考えられますが、そのあたり、何か対策されているのかとかは、私は知らないです。「アドレス空間だけ大きく確保して、使う分だけコミットする」という手法は、使っていないアドレス空間についてはTLBを圧迫しないので、いけそうな気がしますが、どうなのかなあ…。
実際の処理を考えると、個々のメモリーブロックごとに4KB(1ページ)確保するというのはちょっと無理があります。メモリーブロックのサイズはほとんどの場合1KBにも満たないので、ページ数をバカ食いすることになります。大きなメモリーブロックに限定するならいいかもしれません。
メモリー容量の変更が行われるような処理として、私が一番のくせ者だと思うのは、文字列処理です。最大文字数が特に制限されておらず、必要に応じて容量が拡張されるようなタイプの文字列インスタンスは、メモリー容量変更の際の変更する単位がどれくらいかにもよりますが、メモリーの確保解放を繰り返すことになります。一方、先に書いた手法だと最低でも4KBはないと効果は出ませんが、1つの文字列で4KBに達することはかなりまれです。どう実装するのがいいのかなあ…。