NOT A HOTEL TECH TALK ーSOFTWARE 3.0への道筋ー NEXT Web3 (2024-08-07)
はじめに 本記事は、 DeNA Advent Calendar 2020 の 11 日目の記事です。 突然ですが、「コンパイラのコードを読んでみよう」なんて言われても、「どうせ巨大で難解で複雑なロジックを理解しないと読めないんでしょ?」と思いませんか。 コンパイラの構造を理解しようとしても聞いたことのないような専門用語がずらりと並び、コードを読もうとしたらそれらをすべて完全に理解してないと一行も理解できないんじゃないか...。Go のコンパイラ gc のソースコードを読むまでは、私もそう思っていました。 しかし、あまりにも暇な休日のある日、思い立って gc のコードを読んでみました。すると、「コンパイル」という難解な響きの処理も、一つひとつを小さなタスクに分解することで、少しずつ読み進めることができると分かったのです! 何よりも感動したことは、 gc そのものが全て Go で書かれていて、
はじめに GoのGC(Garbage Collection)を調べる中で学んだことをなるべく分かりやすく簡潔にまとめたものです。 GCのアルゴリズムやメモリ割り当てについてまとめています。 記事内で使われている「オブジェクト」という用語はGoにおいては適切でないかもしれませんが、説明のしやすさから使用しています。 概要を把握しやすいように単純化しているため細部は正確でない部分があります。 GC基本 用語集 前提となる用語です。 ルート ルートとは、オブジェクトが到達可能か(生存しているか)を判定するための始点です。 プログラミング言語にもよりますが、基本的にメモリのスタック領域がルートになります。 フラグメンテーション フラグメンテーションとは、使用可能なメモリが断片化し途切れ途切れになっている状態です。 フラグメンテーションになってしまうと、総量的にはメモリが空いていてもアプリケーション
なぜGo言語はコンパクションを採用していないのか GoogleのRick Hudson氏によるISMM 2018 Keynote “Getting To Go”を参照すると、以下のことがわかります。 2014年の時点では”Read barrier free concurrent copying GC”を計画していた しかし期間的な制約から断念し、CMSに舵を切った(この時期に彼らは、ランタイムをCからGoに書き換える作業も行う必要がありました。Changes to the runtime) TCMallocをベースとしたメモリアロケーターを採用することで、断片化およびアロケーションの速度の問題を解決した Go言語のメモリアロケーションについては、ランタイムのコードのコメントにも詳しく記載されています。 malloc.go This was originally based on tcmal
本稿は、ブダペストで開かれたイベント「 RuPy 」で、Pat Shaughnessyが披露したプレゼンの内容をまとめたものです。 プレゼンの映像はここ から視聴できます。 本稿は当初、 同氏の個人ブログ に投稿されましたが、同氏の了承を得て、Codeshipに再掲載します。 このイベントは「RubyとPython」に関するカンファレンスなので、RubyとPythonでは、ガベージコレクション(以下「GC」)の動作がどう違うのかを比較すると面白いだろうと私は思いました。 ただしその本題に入る前に、そもそもなぜ、GCを取り上げるのかについてお話しします。正直言って、すごく魅力的な、わくわくするテーマではないですよね? 皆さんの中でGCと聞いて、心がときめいた方はいらっしゃいますか? [実はこのカンファレンス出席者の中で、ここで手を挙げた人は数名いました!] Rubyコミュニティで最近、Rub
ほとんどの開発者は、自動のガベージコレクション(GC)を当たり前のように使っています。これは、私たちの仕事を容易にするために言語ランタイムが提供する素晴らしい機能の1つです。 しかし、最新のガベージコレクタの中をのぞいてみれば、実際の仕組みは非常に理解しづらいことが分かります。実装の詳細が無数にあるため、それが何をしようとしているのか、また、それがとんでもなく間違った事態を引き起こしかねないことについて十分理解していない限り、すっかり混乱してしまうでしょう。 そこで、5種類のガベージコレクションアルゴリズムを持つおもちゃを作ってみました。小さいアニメーションはランタイムの動作から作成しました。もっと大きいアニメーションとそれを作成するコードは github.com/kenfox/gc-viz で見ることができます。単純なアニメーションによってこうした重要なアルゴリズムを明らかにできることは
プログラムの実行時イメージ 突然だが、本章を始めるに先立ち、プログラム実行時のメモリ空間の状態につ いて予習をしておこうと思う。この章ではコンピュータの低レベルな部分にか なり踏み込んでいくことになるので、あらかじめある程度の知識を仕入れてお かないと太刀打ちできないのだ。それにこの後の章になればいずれ必要になっ てくる。ここで一回やってしまえば後が楽だ。 セグメント 一般的なCプログラムではメモリ空間の中に以下の部分を持つ。 テキスト領域 スタティック変数やグローバル変数の置場 マシンスタック ヒープ テキスト領域はコードが置いてあるところ。二番目は見ての通り。マシンスタッ クには関数の引数やローカル変数が積まれる。ヒープはmalloc()で割り当てて もらうところだ。 三つめのマシンスタックについてもう少し話そう。マシン「スタック」と言う くらいだから当然スタック構造をしている。つまり
メモリリークに悩まされている技術者は多いだろう。メモリリークが嫌でGCという技術が開発されたといっても過言ではないし、歴史的にはC++からJavaへシフトが起きた大きな理由のひとつといっていい。Unix系の簡単な定義でいえば、ヒープ領域を指すポインタ(アドレス)をロストしてしまえばそのメモリはもう漏れたといってよい。たとえばこういったコードだ。 struct { int i; char c; } spam; int main(){ void* p; int i; for(i=0; i<1024; ++i){ p = malloc(sizeof(struct spam)); } pause(); } このコードではpause(3)の時点で約5KBのメモリが漏れている。free(3)を使えばメモリをOSに返却できるが、アドレスが分からないので返却できない。 ところが、ここでいいたいのは、メモリ
そういえば C++ のヘッダファイルを #include するだけで使える GC を書きました。使い方は下のサンプルコードを見てもらえばいいとして、特徴としては、 ヘッダファイルを #include するだけで使える C++ の標準機能だけを使っているのでポータブル*1 mark-and-sweep, precise GC ってなあたりでしょうか。コードは GitHub - kazuho/picogc: a tiny, portable, precise, mark-and-sweep GC in C++ にあります。 C++ のプロジェクトで、ちょっとここだけは GC がほしいんだけど、ってなケースで使いやすいと思います。速度も、そこそこでるんじゃないかな*2。 というわけで、以下、サンプルコード。軽く説明しておくと、 GC を使うクラスは picogc::gc_object を継承する
gcbook, gcai, GCGCLoverのみなさん、お待たせしました。「ガベージコレクションのアルゴリズムと実装」の情報公開です。 書名:ガベージコレクションのアルゴリズムと実装 著者:中村 成洋/相川 光 監修:竹内 郁雄 ページ数:472ページ 本体価格:3,200円 発売開始日:2010年3月17日(水) ※地域・書店によって遅れることがあります ISBN:978-4-7980-2562-9 C3055 読み所 本書は次の2つのテーマを扱います。 1.GCのアルゴリズム(アルゴリズム編) 2.GCの実装(実装編) アルゴリズム編では、これまでに考案されてきた数多くのGCアルゴリズムの中 から、重要なものを厳選して紹介します。伝統的かつ基本的なものから、やや 高度なアルゴリズムを選定しています。GC独特の考え方や各アルゴリズムの特 性などを理解していただくのがアルゴリズム編の最大
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く