Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
わだあつし @watsRuby 2.0 のBitmap Marking GCって美味しいの?Tuesday, December 4, 2012
自己紹介• わだあつし @wats• 株式会社 寿限無やってます• fukuoka.rb とか coder dojo とか fukuoka.pyとか明星和楽とか• 来年からスクールをはじめます!Tuesday, December 4, 2012
• Garbage Collection ( =ゴミ 収集)• メモリの自動開放機構GCのおさらいTuesday, December 4, 2012
• 不要になったオブジェクト = メモリ領域• どうやって判定するのか?ゴミとは?Tuesday, December 4, 2012
• シンプルなMark & Sweep 方式• 必要なオブジェクトをマークして、マークされなかったものをゴミ認定• JavaのGenerational GCのような生存期間に合わせた再配置などもない。• そもそもコンパクションの機構もないみたい...
• Ruby1.9まではマークされたことを示すフラグは各オブジェクト構造体の中にある。• GCを行うと生存するオブジェクトに変更が入るということ• マークする = write している。マーク( = オブジェクトへの変更)Tuesday, De...
• fork()というシステムコールを内部で使っているのがほとんどらしい• fork() : 子プロセスを作る唐突にRack アプリケーションの一般的な構造Tuesday, December 4, 2012
• 生成当初は親プロセスのメモリをそのまま参照する。子プロセス生成の動き1(OSによるかも。)Tuesday, December 4, 2012
• 子プロセスからそこへの書き込み = write が発生して初めてプロセス毎の差異がでる。子プロセス生成の動き(OSによるかも。)Tuesday, December 4, 2012
• その時その部分のメモリ領域を子プロセスが複製 =copyし、そこに書き込む = write する。• これがいわゆる copy on write• だから、親プロセスからはメモリは元の状態のまま子プロセス生成の動き(OSによるかも。)Tue...
write があるとcopyTuesday, December 4, 2012
GCが走ると生存しているオブジェクトにマークのためwriteされる。Tuesday, December 4, 2012
オブジェクトに実質的に差異が発生していないのにプロセスごとに全てコピーされるTuesday, December 4, 2012
これがサーバサイドRubyのメモリ消費を増大させている。Tuesday, December 4, 2012
• writeされているのは、生存していることを示すマーク用の1bitだけ• なら、オブジェクトはそのままプロセス間で共有させておきたい。• マーク用1bitだけを別領域にだしちゃおうこれを何とかしたい!Tuesday, December 4,...
• GCのマーク用1bitだけを、オブジェクトから別領域に抜き出し• GC時のwriteがその別領域だけになるので、オブジェクトは共有のまま• 最低限のオブジェクトのコピーだけが発生するようになる。それが Bitmap Marking GCTu...
• Unicorn や Passenger使っているところではメモリ消費が下がるはず。• GCの際のマークに1step増えるので、GCの時間は微増らしい• 子プロセス作らんようなところ(ただのrubyスクリプトとか)には恩恵ないかとまとめTue...
• なんでOSのスレッド使わんのですっけ?そもそもTuesday, December 4, 2012
• 今日のパクリ元• http://patshaughnessy.net/2012/3/23/why-you-should-be-excited-about-garbage-collection-in-ruby-2-0• http://www....
大分おおざっぱなメモリモデルのおさらいTuesday, December 4, 2012
スタック領域とヒープ領域に論理的に分けて使うTuesday, December 4, 2012
メソッドコール毎にスタックにスタックフレームが積まれるTuesday, December 4, 2012
Rubyの場合、全てオブジェクトなのでヒーブに作られる。Tuesday, December 4, 2012
• ※実際は、ローカル変数を束縛したProcを返したりするので、もっと複雑。あくまで概要メソッドが終了すると、そのスタックフレームがpopされ、前のメソッド(スタックフレーム)の途中から再開Tuesday, December 4, 2012
Mark & SweepのおさらいTuesday, December 4, 2012
ヒープにはどんどんオブジェクトができるのでいつか足りなくなる。Tuesday, December 4, 2012
もう使わなくなったオブジェクトもあるはず。。。Tuesday, December 4, 2012
• 参照は、直接も間接も含む使わなくなったオブジェクト = メソッド(スタックフレーム)からの参照がないTuesday, December 4, 2012
• こいつが「write」してるスタックから参照があるオブジェクトを再帰的にたどってマークする。Tuesday, December 4, 2012
• = 要らない子• = GC対象マークされなかったものは参照されていない。Tuesday, December 4, 2012
そのアドレスを要らない子リストに追加して、今後そこからメモリを供給していくTuesday, December 4, 2012
Upcoming SlideShare
Loading in …5
×

Bitmap marking GC

622 views

Published on

  • Be the first to comment

  • Be the first to like this

Bitmap marking GC

  1. 1. わだあつし @watsRuby 2.0 のBitmap Marking GCって美味しいの?Tuesday, December 4, 2012
  2. 2. 自己紹介• わだあつし @wats• 株式会社 寿限無やってます• fukuoka.rb とか coder dojo とか fukuoka.pyとか明星和楽とか• 来年からスクールをはじめます!Tuesday, December 4, 2012
  3. 3. • Garbage Collection ( =ゴミ 収集)• メモリの自動開放機構GCのおさらいTuesday, December 4, 2012
  4. 4. • 不要になったオブジェクト = メモリ領域• どうやって判定するのか?ゴミとは?Tuesday, December 4, 2012
  5. 5. • シンプルなMark & Sweep 方式• 必要なオブジェクトをマークして、マークされなかったものをゴミ認定• JavaのGenerational GCのような生存期間に合わせた再配置などもない。• そもそもコンパクションの機構もないみたい!今までの Ruby GCTuesday, December 4, 2012
  6. 6. • Ruby1.9まではマークされたことを示すフラグは各オブジェクト構造体の中にある。• GCを行うと生存するオブジェクトに変更が入るということ• マークする = write している。マーク( = オブジェクトへの変更)Tuesday, December 4, 2012
  7. 7. • fork()というシステムコールを内部で使っているのがほとんどらしい• fork() : 子プロセスを作る唐突にRack アプリケーションの一般的な構造Tuesday, December 4, 2012
  8. 8. • 生成当初は親プロセスのメモリをそのまま参照する。子プロセス生成の動き1(OSによるかも。)Tuesday, December 4, 2012
  9. 9. • 子プロセスからそこへの書き込み = write が発生して初めてプロセス毎の差異がでる。子プロセス生成の動き(OSによるかも。)Tuesday, December 4, 2012
  10. 10. • その時その部分のメモリ領域を子プロセスが複製 =copyし、そこに書き込む = write する。• これがいわゆる copy on write• だから、親プロセスからはメモリは元の状態のまま子プロセス生成の動き(OSによるかも。)Tuesday, December 4, 2012
  11. 11. write があるとcopyTuesday, December 4, 2012
  12. 12. GCが走ると生存しているオブジェクトにマークのためwriteされる。Tuesday, December 4, 2012
  13. 13. オブジェクトに実質的に差異が発生していないのにプロセスごとに全てコピーされるTuesday, December 4, 2012
  14. 14. これがサーバサイドRubyのメモリ消費を増大させている。Tuesday, December 4, 2012
  15. 15. • writeされているのは、生存していることを示すマーク用の1bitだけ• なら、オブジェクトはそのままプロセス間で共有させておきたい。• マーク用1bitだけを別領域にだしちゃおうこれを何とかしたい!Tuesday, December 4, 2012
  16. 16. • GCのマーク用1bitだけを、オブジェクトから別領域に抜き出し• GC時のwriteがその別領域だけになるので、オブジェクトは共有のまま• 最低限のオブジェクトのコピーだけが発生するようになる。それが Bitmap Marking GCTuesday, December 4, 2012
  17. 17. • Unicorn や Passenger使っているところではメモリ消費が下がるはず。• GCの際のマークに1step増えるので、GCの時間は微増らしい• 子プロセス作らんようなところ(ただのrubyスクリプトとか)には恩恵ないかとまとめTuesday, December 4, 2012
  18. 18. • なんでOSのスレッド使わんのですっけ?そもそもTuesday, December 4, 2012
  19. 19. • 今日のパクリ元• http://patshaughnessy.net/2012/3/23/why-you-should-be-excited-about-garbage-collection-in-ruby-2-0• http://www.narihiro.info/resource/presen/bitmap_gc.pdf• Rubyのスタックフレーム• http://i.loveruby.net/ja/hack/frame.html• Ruby Enterprise Edition はそもそもそんなGCらしい• http://www.rubyenterpriseedition.com/download.html参考Tuesday, December 4, 2012
  20. 20. 大分おおざっぱなメモリモデルのおさらいTuesday, December 4, 2012
  21. 21. スタック領域とヒープ領域に論理的に分けて使うTuesday, December 4, 2012
  22. 22. メソッドコール毎にスタックにスタックフレームが積まれるTuesday, December 4, 2012
  23. 23. Rubyの場合、全てオブジェクトなのでヒーブに作られる。Tuesday, December 4, 2012
  24. 24. • ※実際は、ローカル変数を束縛したProcを返したりするので、もっと複雑。あくまで概要メソッドが終了すると、そのスタックフレームがpopされ、前のメソッド(スタックフレーム)の途中から再開Tuesday, December 4, 2012
  25. 25. Mark & SweepのおさらいTuesday, December 4, 2012
  26. 26. ヒープにはどんどんオブジェクトができるのでいつか足りなくなる。Tuesday, December 4, 2012
  27. 27. もう使わなくなったオブジェクトもあるはず。。。Tuesday, December 4, 2012
  28. 28. • 参照は、直接も間接も含む使わなくなったオブジェクト = メソッド(スタックフレーム)からの参照がないTuesday, December 4, 2012
  29. 29. • こいつが「write」してるスタックから参照があるオブジェクトを再帰的にたどってマークする。Tuesday, December 4, 2012
  30. 30. • = 要らない子• = GC対象マークされなかったものは参照されていない。Tuesday, December 4, 2012
  31. 31. そのアドレスを要らない子リストに追加して、今後そこからメモリを供給していくTuesday, December 4, 2012

×