Mercurial > hg > Papers > 2020 > anatofuz-sigos
changeset 36:a039a55d97ae
..
author | anatofuz <anatofuz@cr.ie.u-ryukyu.ac.jp> |
---|---|
date | Tue, 05 May 2020 17:08:08 +0900 |
parents | c2ba9cdb4916 |
children | 9e40a7a00a02 |
files | paper/anatofuz-sigos.md paper/anatofuz-sigos.pdf paper/anatofuz-sigos.tex |
diffstat | 3 files changed, 16 insertions(+), 18 deletions(-) [+] |
line wrap: on
line diff
--- a/paper/anatofuz-sigos.md Tue May 05 16:17:38 2020 +0900 +++ b/paper/anatofuz-sigos.md Tue May 05 17:08:08 2020 +0900 @@ -95,7 +95,7 @@ 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。 また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。 -MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。 +MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。 ![lab:meta-cg-dg, cap:CodeGearとMetaCodeGear](./fig/meta-cg-dg.pdf) @@ -112,7 +112,7 @@ ![lab:fig:context_ref, cap:Contextと各データの関係図](fig/Context_ref.pdf) コード上では別のCodeGearに直接遷移している様に見えるが、 実際はcontext内の遷移先のCodeGearに対応するスロットから、対応するMetaCodeGearに遷移する。 -MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。 +MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。 # xv6 kernel @@ -128,7 +128,7 @@ 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。 -本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。 +本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。 # xv6のシステムコールの継続の分析 @@ -162,8 +162,8 @@ システムコールの一連の流れに着目するのではなく、 特定の対象のAPIに着目して継続の分析を検討した。 xv6のファイルシステムに関する定義ファイルは`fs.c`中に記述されている。 -Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。 -`__code`から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合への名前となる。 +Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。 +`__code`から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合の最初の継続となる。 ``` lab:src:fs_interface, cap:ファイルシステム操作のAPIの一部 @@ -180,10 +180,9 @@ } fs; ``` +Code\ref{src:fs_interface}内の `readsb`などは`fs.c`内で定義されているCの関数名と対応している。 +このCの関数を更に継続ごとに分割するために、 関数内のif文などの分岐を持たない基本単位であるBasic Blockに着目した。 -# Basic Blockに基づく分析 - -まず関数内でif文などの分岐を持たない基本単位であるBasic Blockに着目した。 CbCのCodeGearの粒度はCの関数とアセンブラの中間であるといえるので、 BasicBlockをCodeGearに置き換える事が可能である。 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することが可能となる。 @@ -227,4 +226,4 @@ グローバル変数を使用してしまうと、 CodeGearで定義した状態がDataGear以外のグローバル変数によって変更されてしまう。 グローバル変数を極力使わず継続を中心とした実装を行いたい。 -contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。 +contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。
--- a/paper/anatofuz-sigos.tex Tue May 05 16:17:38 2020 +0900 +++ b/paper/anatofuz-sigos.tex Tue May 05 17:08:08 2020 +0900 @@ -183,7 +183,7 @@ 遷移する各CodeGearの実行に必要なデータの整合性の確認などのメタ計算は、 MetaCodeGearと呼ばれる各CodeGearごと実装されたCodeGearで計算を行う。 このMetaCodeGearの中で参照されるDataGearをMetaDataGearと呼ぶ。 また、 対象のCodeGearの直前で実行されるMetaCodeGearをStubCodeGearと呼ぶ。 -MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。 +MetaCodeGearやMetaDataGearは、プログラマが直接実装することはなく、 現在はPerlスクリプトによってGearsOSのビルド時に生成される。 CodeGearから別のCodeGearに遷移する際のDataGearなどの関係性を、図\ref{meta-cg-dg}に示す。 \begin{figure}[tb] @@ -212,7 +212,7 @@ \end{figure} コード上では別のCodeGearに直接遷移している様に見えるが、 実際はcontext内の遷移先のCodeGearに対応するスロットから、対応するMetaCodeGearに遷移する。 -MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。 +MetaCodeGear中で、次に実行するCodeGearで必要なDataGearをcontextから取り出し、 実際の計算が行われる。 \section{xv6 kernel} @@ -228,7 +228,7 @@ 本論文ではxv6のファイルシステム関連の内部処理と、システムコール実行時に実行される処理について分析を行う。 xv6 kernelのファイルシステムは階層構造で表現されており、 最も低レベルなものにディスク階層、 抽象度が最も高いレベルのものにファイル記述子がある。 -本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。 +本論文ではxv6の継続の分析をシステムコール部分とファイルシステム、 仮想メモリなどのOSの根幹部分でそれぞれ行った。 \section{xv6のシステムコールの継続の分析} @@ -268,8 +268,8 @@ システムコールの一連の流れに着目するのではなく、 特定の対象のAPIに着目して継続の分析を検討した。 xv6のファイルシステムに関する定義ファイルは`fs.c`中に記述されている。 -Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。 -\texttt{\_\_code}から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合への名前となる。 +Code\ref{src:fs_interface}に示す様に、 `fs.c`中に定義されているAPIを抜き出し、 CbCのInterfaceとして定義した。 +\texttt{\_\_code}から始まるCodeGearの名前が、 それぞれ抽象化されたCodeGearの集合の最初の継続となる。 \begin{lstlisting}[frame=lrbt,label=src:fs_interface,caption={ファイルシステム操作のAPIの一部}] @@ -286,10 +286,9 @@ } fs; \end{lstlisting} +Code\ref{src:fs_interface}内の \texttt{readsb}などは`fs.c`内で定義されているCの関数名と対応している。 +このCの関数を更に継続ごとに分割するために、 関数内のif文などの分岐を持たない基本単位であるBasic Blockに着目した。 -\section{Basic Blockに基づく分析} - -まず関数内でif文などの分岐を持たない基本単位であるBasic Blockに着目した。 CbCのCodeGearの粒度はCの関数とアセンブラの中間であるといえるので、 BasicBlockをCodeGearに置き換える事が可能である。 したがって特定の関数内の処理のBasicBlockを分析し、 BasicBlockに対応したCodeGearへ変換することが可能となる。 @@ -333,7 +332,7 @@ グローバル変数を使用してしまうと、 CodeGearで定義した状態がDataGear以外のグローバル変数によって変更されてしまう。 グローバル変数を極力使わず継続を中心とした実装を行いたい。 -contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。 +contextは現在プロセス構造体に埋め込まれており、 kernelそのものの状態を制御するためには各contextを管理する機能が必要であると考えられる。 \nocite{*} \bibliographystyle{ipsjunsrt}