Mercurial > hg > Papers > 2019 > ikki-sigos



<!DOCTYPE html>
<html>
<head>
   <meta http-equiv="content-type" content="text/html;charset=utf-8">
   <title>分散ネットワークChristieによるBlockchainの実装</title>

   <meta name="generator" content="Slide Show (S9) v4.0.1 on Ruby 2.3.7 (2018-03-28) [universal.x86_64-darwin16]">
   <meta name="author"    content="Takahiro Ikki, Shinji Kono" >

<!-- style sheet links -->
<link rel="stylesheet" href="s6/themes/screen.css"       media="screen">
<link rel="stylesheet" href="s6/themes/print.css"        media="print">
<link rel="stylesheet" href="s6/themes/blank.css"        media="screen,projection">

<!-- JS -->
<script src="s6/js/jquery-1.11.3.min.js"></script>
<script src="s6/js/jquery.slideshow.js"></script>
<script src="s6/js/jquery.slideshow.counter.js"></script>
<script src="s6/js/jquery.slideshow.controls.js"></script>
<script src="s6/js/jquery.slideshow.footer.js"></script>
<script src="s6/js/jquery.slideshow.autoplay.js"></script>

<!-- prettify -->
<link rel="stylesheet" href="scripts/prettify.css">
<script src="scripts/prettify.js"></script>

<style>
  .slide {page-break-after: always;}
</style>


</head>
<body>

<div class="layout">
  <div id="header"></div>
  <div id="footer">
    <div align="right">
      <img src="s6/images/logo.svg" width="200px">
    </div>
  </div>
</div>

<div class="presentation">

  <div class='slide cover'>
    <table width="90%" height="90%" border="0" align="center">
      <tr>
        <td>
          <div align="center">
              <h1><font color="#808db5">分散ネットワークChristieによるBlockchainの実装</font></h1>
          </div>
        </td>
      </tr>
      <tr>
        <td>
          <div align="left">
               Takahiro Ikki, Shinji Kono
               琉球大学
            <hr style="color:#ffcc00;background-color:#ffcc00;text-align:left;border:none;width:100%;height:0.2em;">
          </div>
        </td>
      </tr>
    </table>
  </div>


<div class='slide'>

<!-- _S9SLIDE_ -->
<h2 id="研究目的">研究目的</h2>

<ul>
  <li>コンピュータのデータの不整合は, 誤作動や複数人によるデータの同時書き込みによって発生し, 特に分散環境下で問題となる.</li>
  <li>ブロックチェーンはデータの分散ができ, 不整合の検知が可能な仕組みとなっている.</li>
  <li>当研究室で開発中のGearsOSの分散システムの技術として, ブロックチェーンが使用できるか調査中である.</li>
  <li>将来的にGearsOSに組み込む予定のある分散フレームワークChristieに分散フレームワークを実装することにした. (?次にも同様の記述がある)</li>
</ul>

<!--
# OS の拡張性と信頼性の両立

-->


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="christie">Christie</h2>
<ul>
  <li>Christieは当研究室で開発している分散フレームワークである.</li>
  <li>現在はjava上で開発されているが, GearsOSに組み込む予定があるため, 言語Continuation based Cへ書き換え可能な構成となっている. (?GeasOSの解説がより欲しい？)</li>
  <li>言語CbCと近い概念として以下の概念が存在する。
    <ul>
      <li>CodeGear(以下CG)</li>
      <li>CodeGearManager(以下CGM)</li>
      <li>DataGear(以下DG)</li>
      <li>DataGearManager(以下DGM)</li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="christieの言語概念">Christieの言語概念</h2>
<ul>
  <li>CGはスレッド, クラスに相当し, javaの継承を用いて記述する.</li>
  <li>DGは変数データに相当し, CG内でアノテーションを用いて変数データを取り出せる.</li>
  <li>CGMはノードであり, DG, CG, DGMを管理する.</li>
  <li>DGMはDGを管理するものであり, putという操作により, 変数データ(DG)を格納できる.
    <ul>
      <li>DGMにはLocalDGMとRemoteDGMが存在する。LocalDGMは各ノード固有のデータベースである。RemoteDSMは他ノードのLocalDGMに対応するproxyであり、接続しているノードの数だけ存在する。</li>
      <li>DGMのput操作を行う際にはLocalとRemoteのどちらかを選ぶ.Localであれば、LocalのCGMが管理するDGMに対しDGを格納し, Remoteの場合は接続したRemoteさきのCGMのDGMにDGを格納する.</li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="dgm">DGM</h2>
<ul>
  <li>RocalDGMを立ち上げるにはDataSegmentクラスが提供する、connectメソッドを用い、接続したいポートのipアドレスとport番号、そして任意のManager名を指定することで立ち上げる。</li>
  <li>立ち上げ後はManager名を指定してDataSegmentAPI用いてDSのやり取りを行うため、プログラマはManager名を意識することでLocalへの操作もRemoteへの操作も同様に扱える。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="dgのアノテーション">DGのアノテーション</h2>
<ul>
  <li>DGを取り出す際にはCG内で宣言した変数データにアノテーションをつける。DGアノテーションには
Take、Peek、TakeFrom、PeekFrom、の4つがある。
    <ul>
      <li>Take
        <ul>
          <li>先頭のDGを読み込み、そのDGを削除する。</li>
        </ul>
      </li>
      <li>Peek
        <ul>
          <li>先頭のDGを読み込むが、DGが消去されない。そのため特に操作をしない場合、同じデータを参照し続ける。</li>
        </ul>
      </li>
      <li>TakeFrom
        <ul>
          <li>Takeと似ているが、Remote DGM nameをしているすることで、その接続先のDGM からTake操作をおこえる。</li>
        </ul>
      </li>
      <li>PeekFrom
        <ul>
          <li>Peekと似ているが、 Remote DGM nameをしているすることで、その接続先のDGM からPeek操作をおこえる。</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="christieのコード例">Christieのコード例</h2>
<pre><code class="language-code">package christie.example.HelloWorld;

import christie.codegear.CodeGearManager;
import christie.codegear.StartCodeGear;

public class StartHelloWorld extends StartCodeGear {

    public StartHelloWorld(CodeGearManager cgm) {
        super(cgm);
    }

    public static void main(String[] args){
        CodeGearManager cgm = createCGM(10000);
        cgm.setup(new HelloWorldCodeGear());
        cgm.getLocalDGM().put("helloWorld","hello");
        cgm.getLocalDGM().put("helloWorld","world");
    }
}

</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="annottation">Annottation</h2>
<ul>
  <li>ChristieではInputDGの指定にはアノテーションを使う。</li>
  <li>アノテーションとはクラスやメソッド、パッケージに対して、付加情報を記述できるJavaのMeta Computationである。</li>
  <li>先頭に@をつけることで記述し、オリジナルのアノテーションを定義することもできるInput
となる型の変するを直接宣言し、変数名としてkeyを記述する。その上にアノテーションでTakeもしくはPeekを指定する。
    <pre><code class="language-code">@Take
public String name;
</code></pre>
    <pre><code class="language-code">@TakeFrom("remote")
public String name;
</code></pre>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="topologymanager">TopologyManager</h2>
<ul>
  <li>TopologyManagerとはTopologyを形成するために、参加を表明したノード、TopologyNodeに名前を与え、必要があればノード同士の配線を行うノードである。</li>
  <li>TopologyManagerのTopology形成方法として、静的Topologyと動的Topologyがある。</li>
  <li>動的Topologyは参加を表明したノードに対し、動的にノード同士の関係を作る。例えばTreeを構成する場合、参加したノードから順にrootに近い役割を与え、またCodeGearはノードが参加し、parentに接続された後に実行される。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="静的topology">静的Topology</h2>
<ul>
  <li>静的Toopologyはdotファイルを与えることでノード関係を下の図のようにする。</li>
  <li>静的Topologyはdotファイルのノード数と同等のTopologyNodeがあって初めて、CodeGearが実行される。
    <pre><code class="language-Code">digraph test {
  node0 -&gt; node1 [label="right"]
  node1 -&gt; node2 [label="right"]
  node2 -&gt; node0 [label="right"]
}
</code></pre>
  </li>
</ul>

<div style="text-align: center;">
　<img src="../paper/images/ring.pdf" alt="MetaGear" width="300" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="ブロックチェーンのトランザクション">ブロックチェーンのトランザクション</h2>
<ul>
  <li>ブロックチェーンはP2Pにてネットワーク間が動作している。つまり、ブロックチェーンにはサーバー、クライアントの区別がなく全てのノードが平等である。</li>
  <li>ブロックチェーンにおけるブロックは複数のトランザクションをまとめたものである。ブロックの構造は使用するコンセンサスにより変わるが基本的には、previous block hash, merkle root hash, timeが含まれるBlockHeaderとTransactionListにより構成される。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="blockheader">BlockHeader</h2>
<ul>
  <li>BlockHeaderには、前のブロックをハッシュ化したもの、トランザクションをまとめたmarkle treeのrootのhash、そのブロックを生成したtimeとなっている。</li>
  <li>previous block hashは、前のブロックのパラメータを並べてhash化したものである。</li>
  <li>上記のものがそれぞれ連なっていることによって下の図のようなブロック繋がっている。そのため一つが更新されたらそのあとにつながるブロック全てを更新しなければならなくなる。</li>
</ul>
<div style="text-align: center;">
　<img src="../paper/images/chain.pdf" alt="MetaGear" width="600" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="blockの動作">Blockの動作</h2>
<ul>
  <li>ブロックが生成された場合、知っているノードにそのブロックをブロードキャストする。通信量を抑えるためにブロックを送ったあと、ブロックをシリアライズして送信する場合もある。</li>
  <li>誤りがあればさらにそのノードがブロックをブロードキャストする。そしてTransaction PoolというTransactionをためておく場所から、そのブロックに含まれるTransactionを削除し、新しいブロックを生成する。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="transaction">Transaction</h2>
<ul>
  <li>トランザクションとはデータのやり取りを行なった記録の最小単位である。トランザクションの構造は次のとおりである。</li>
  <li>TransactionHash
    <ul>
      <li>トランザクションをハッシュ化したもの。</li>
    </ul>
  </li>
  <li>data
    <ul>
      <li>データ</li>
    </ul>
  </li>
  <li>sendAddress
    <ul>
      <li>送り元のアドレス。</li>
    </ul>
  </li>
  <li>receiveAddress
    <ul>
      <li>送り先のアカウントのアドレス。</li>
    </ul>
  </li>
  <li>signature
    <ul>
      <li>トランザクションの一部と秘密鍵をSHA256でハッシュ化したもの。ECDSAで署名している。</li>
    </ul>
  </li>
  <li>トランザクションはノード間で伝搬され、ノードごとに検証される。そして検証を終え、不正なトランザクションであればそれを破棄し、検証に通った場合はTransaction Poolに取り込まれ、また検証したノードからトランザクションがブロードキャストする。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h2 id="コンセンサスアルゴリズム">コンセンサスアルゴリズム</h2>
<ul>
  <li>fork
    <ul>
      <li>ブロック生成後にブロードキャストを行うと、ブロック高の同じもしくは高いブロックチェーンにたどり着く状態があり、異なるブロックを持った二つのブロックチェーンのうちどちらかを破棄する必要がある。</li>
    </ul>
  </li>
  <li>fork状態を解消するために用いられるのがコンセンサスアルゴリズムである。</li>
  <li>ブロックチェーンはパブリックブロックチェーンとコンソーシアムブロックチェーンの場合によってコンセンサスアルゴリズムが変わる。
    <ul>
      <li>パブリックブロックチェーン
        <ul>
          <li>不特定たすのノードが参加するブロックチェーンを指す。</li>
          <li>不特定多数のノード間、全体のノードの参加数が変わる状況でコンセンサスの変わるアルゴリズムでなければならない。</li>
        </ul>
      </li>
      <li>コンソーシアムブロックチェーン
        <ul>
          <li>許可したノードのみが参加できるブロックチェーンである。</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxos">Paxos</h1>
<ul>
  <li>Paxosはノードの多数決によってコンセンサスをとるアルゴリズムである。</li>
  <li>Paxosは以下のような問題があっても値を一意に決めることができる。
    <ul>
      <li>1,プロセス毎に処理の速度が違う。つまりメッセージの返信が遅い可能性がある。</li>
      <li>2,通信にどれだけの時間がかかるかわからず、その途中でメッセージが失われる可能性がある。</li>
      <li>3,プロセスは停止する可能性もある。</li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxosの役割ノード">Paxosの役割ノード</h1>
<ul>
  <li>Paxosは3つの役割ノードがある。
    <ul>
      <li>proposer
        <ul>
          <li>値を提案するノード。</li>
        </ul>
      </li>
      <li>accepter
        <ul>
          <li>値を決めるノード。</li>
        </ul>
      </li>
      <li>lerner
        <ul>
          <li>accepterから値を集計し、過半数以上のaccepterが持っている値を決める。</li>
        </ul>
      </li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxosの役割定義">Paxosの役割定義</h1>
<ul>
  <li>提案
    <ul>
      <li>異なる提案ごとにユニークな提案番号と値からなる。提案番号とは、異なる提案を見分けるための識別子であり、単調増加である。</li>
    </ul>
  </li>
  <li>値(提案)がacceptされる
    <ul>
      <li>accepterによって値(提案)が決まること。</li>
    </ul>
  </li>
  <li>値(提案)が選択(chosen)される
    <ul>
      <li>過半数以上のacceptorによって、値がacceptされた場合、それを値(提案)が選択されたと言う。</li>
    </ul>
  </li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxosのアルゴリズム">paxosのアルゴリズム</h1>
<ul>
  <li>paxosのアルゴリズムは2フューズあり、一つ目のフェーズprepare-promiseと二つ目のフェーズaccept-acceptedの二つに区分される。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxosのアルゴリズム-prepare-promise">paxosのアルゴリズム prepare-promise</h1>
<ul>
  <li>(言葉での説明記入?)</li>
</ul>
<div style="text-align: center;">
　<img src="../paper/images/prepare-promise.pdf" alt="MetaGear" width="600" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxosのアルゴリズム-accept-accepted">paxosのアルゴリズム accept-accepted</h1>
<ul>
  <li>(1)proposerは過半数のacceptorから返事が来たのなら、次の提案をaccepterに送る。これをacceptリクエストという。
    <ul>
      <li>(a)もし、約束のみ帰って来ているのならば、任意の値vをprepareリクエストで送った提案に設定する。</li>
      <li>(b)もし、acceptされた提案が帰って来たら、その中で最大の提案番号v’をprepareリクエストで送った提案の値として設定する。</li>
    </ul>
  </li>
  <li>(2)acceptorはacceptリクエストが来た場合、Promiseした提案よりもacceptリクエストで提案された番号が低ければ、その提案を拒否する。それ以外の場合、acceptする。</li>
</ul>
<div style="text-align: center;">
　<img src="../paper/images/accept-accepted.pdf" alt="MetaGear" width="600" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="paxos-1">Paxos</h1>
<ul>
  <li>Proof of Workと比較しメッセージ通信量と耐障害性のトレードオフになっている。</li>
  <li>Paxosでコンセンサスを取る際、Proof of Workと比較して次のようなメリットがある。
    <ul>
      <li>CPUにリソースを消費しない。</li>
      <li>Transactionの確定に時間がかからない。</li>
    </ul>
  </li>
  <li>Paxos自体がリーダー選出に向いているアルゴリズムである。そのため、リーダーを決定し、そのノードのブロックチェーンの一貫性のみをかんがえることができる。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="gears-os-の構成図">Gears OS の構成図</h1>

<div style="text-align: center;">
　<img src="./fig/gears_structure.pdf" alt="gears_structure" width="900" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="context">Context</h1>
<ul>
  <li>Context とは使用される Code Gear と Data Gear を全て格納した Meta Data Gear である。</li>
  <li>Gears OSは必要なCode Gear、Data Gearに参照したい場合、このContext を通す必要がある。</li>
</ul>
<div style="text-align: center;">
　<img src="./fig/Gearef.pdf" alt="gearef" width="900" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="context-の定義">context の定義</h1>

<pre><code class="language-contexr">/* context define */
struct Context {
    int codeNum; //実行可能な Code Gear の数
    __code (**code) (struct Context*); //実行可能な code Gear のリスト
    void* heapStart; //Data Gear の Allocate用のヒープ
    void* heap;
    long heapLimit;
    int dataNum; //Data Gear の数
    union Data **data; //Data Gear のリスト
};
</code></pre>

<p>#Context</p>
<ul>
  <li>Code/Data Gear の名前は enum で定義される。</li>
  <li>Code/Data Gear の名前とポインタの対応は enum を使って行われる。</li>
</ul>

<pre><code class="language-code">enum Code {
    C_cg1,
    C_cg2,
};
</code></pre>

<pre><code class="language-data">enum Data {
    D_dg1,
    D_dg2,
};
</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="data-gear-の定義">Data Gear の定義</h1>
<ul>
  <li>Data Gear は union と struxt を用いて定義される</li>
  <li>これをもとに必要な Data Gear の allocate を行う</li>
</ul>

<pre><code class="language-data">union Data {
    struct Time {
        enum Code next;
        double time;
    } time;
    struct LoopCounter {
        int i;
    } loopCounter;
    ...
};
</code></pre>

<!--
# CbC による Gears OS 記述の問題点
- Gears OS を CbC で実装する上でメタ計算の記述が煩雑であることがわかった。
- 本研究ではこれらのメタ計算を自動生成することにより Gears OS を記述する上においてより良い構文をユーザーに提供することにした。
- そのためのプロトタイプとして perl スクリプトを作成した。
-->


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="interface">Interface</h1>
<ul>
  <li>Code Gear と Data Gear は Interface と呼ばれるまとまりとして記述される。</li>
  <li>Interface は使用される Data Gear の定義と、それに対する Code Gear の集合である。</li>
  <li>Interface の操作に対応する Code Gear の引数は Interface に定義されている Data Gear を通して行われる。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="interface-のコード">Interface のコード</h1>
<pre><code class="language-interface">typedef struct Stack&lt;Type, Impl&gt;{
        union Data* stack;
        union Data* data;
        union Data* data1;
        __code whenEmpty(...);
        __code clear(Impl* stack,__code next(...));
        __code push(Impl* stack,Type* data, __code next(...));
        __code pop(Impl* stack, __code next(Type* data, ...));
        __code pop2(Impl* stack, __code next(Type* data, Type* data1, ...));
        __code isEmpty(Impl* stack, __code next(...), __code whenEmpty(...));
        __code get(Impl* stack, __code next(Type* data, ...));
        __code get2(Impl* stack, __code next(Type* data, Type* data1, ...));
        __code next(...);
} Stack;
</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="interface-の実装例">Interface の実装例</h1>

<pre><code class="language-impl">Stack* createSingleLinkedStack(struct Context* context) {
    struct Stack* stack = new Stack();
    struct SingleLinkedStack* singleLinkedStack = new SingleLinkedStack();
    stack-&gt;stack = (union Data*)singleLinkedStack;
    singleLinkedStack-&gt;top = NULL;
    stack-&gt;push = C_pushSingleLinkedStack;
    stack-&gt;pop  = C_popSingleLinkedStack;
    stack-&gt;pop2  = C_pop2SingleLinkedStack;
    stack-&gt;get  = C_getSingleLinkedStack;
    stack-&gt;get2  = C_get2SingleLinkedStack;
    stack-&gt;isEmpty = C_isEmptySingleLinkedStack;
    stack-&gt;clear = C_clearSingleLinkedStack;
    return stack;
}
</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="interface-の実装例-1">Interface の実装例</h1>

<pre><code class="language-impl">__code pushSingleLinkedStack(struct SingleLinkedStack* stack,
                                union Data* data, __code next(...)) {
    Element* element = new Element();
    element-&gt;next = stack-&gt;top;
    element-&gt;data = data;
    stack-&gt;top = element;
    goto next(...);
}

</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="interface-の使用例">interface の使用例</h1>

<ul>
  <li>goto interface-&gt;code() と記述する。</li>
</ul>

<pre><code class="language-code">__code stackTest1(struct Stack* stack) {
    Node* node = new Node();
    node-&gt;color = Red;
    goto stack-&gt;push(node, stackTest2);
}

</code></pre>

<!--

<div style="text-align: center;">
　<img src="./images/multiComponent.pdf" alt="message" width="600">
</div>

-->


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="stub-code-gear">stub Code Gear</h1>

<ul>
  <li>Code Gear が必要とする Data Gear を取り出す際に Context を通す必要がある。</li>
  <li>しかし、Meta Data Gear である Context をノーマルレベルの Code Gear から直接アクセスするのはよろしくない。</li>
  <li>そこで Context から必要なデータを取り出して Code Gear に接続する、メタレベルの stub Code Gear を定義し、これを介して間接的に必要な Data Gear にアクセスする。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="stub-code-gear-の例">stub Code Gear の例</h1>
<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
                    struct SingleLinkedStack* stack,enum Code next) {
    stack-&gt;top = NULL;
    goto meta(context, next);
}

__code clearSingleLinkedStack_stub(struct Context* context) {
        SingleLinkedStack* stack =
                (SingleLinkedStack*)GearImpl(context, Stack, stack);
        enum Code next = Gearef(context, Stack)-&gt;next;
        goto clearSingleLinkedStack(context, stack, next);
}
</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="contextstub-code-gear-の自動生成">Context、stub Code Gear の自動生成</h1>
<ul>
  <li>Gears OS ではノーマルレベルの計算の他に Context や stub などのメタ計算を記述する必要がある。</li>
  <li>現在の CbC で Gears OS を記述すると、このメタ計算の記述も行わなくてはならず、これには多くの労力を要する。</li>
  <li>この記述を助けるために Context を生成する generate_context と stub Code Gear を生成する generate_stub を perl スクリプトで作成した。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="stub-code-gear-の生成">stub Code Gear の生成</h1>
<ul>
  <li>stub Code Gear は Code Gear 間の継続に挟まれ、Code Gear が必要な Data Gear を Context から取り出す処理を行うものである。</li>
  <li>stub Code Gear は Code Gear 毎に記述する必要があり、そのCode Gear の引数を見て取り出す Data Gear を選択する。</li>
  <li>generate_stub は指定された cbc ファイルの __code で記述された Code Gear を取得。</li>
  <li>Code Gear の引数と interface を照らし合わせ、Gearef または GearImpl を決定する。</li>
  <li>cbc ファイルの Code Gear から、生成した stub Code Gear を加えたファイルを生成する。</li>
</ul>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="生成された-stub-code-gear">生成された stub Code Gear</h1>

<pre><code class="language-stub">__code clearSingleLinkedStack(struct Context *context,
                    struct SingleLinkedStack* stack,enum Code next) {
    stack-&gt;top = NULL;
    goto meta(context, next);
}

__code clearSingleLinkedStack_stub(struct Context* context) {
        SingleLinkedStack* stack =
                (SingleLinkedStack*)GearImpl(context, Stack, stack);
        enum Code next = Gearef(context, Stack)-&gt;next;
        goto clearSingleLinkedStack(context, stack, next);
}
</code></pre>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="context-の生成">Context の生成</h1>

<ul>
  <li>generate_context は context.h から Data Gear、generate_stub から生成されたファイルから Code Gear を取得し、以下を生成する。
    <ul>
      <li>Code/Data Gear を enum で定義した enumCode.h、enumData.h</li>
      <li>取得した Code/Data Gear から Context の生成を行う target-context</li>
      <li>Context を生成する際の Data Gear の Allocation を行う dataGearInit.c</li>
    </ul>
  </li>
</ul>

<div style="text-align: center;">
　<img src="./fig/generate_context3.pdf" alt="generate_context3" width="600" />
</div>


</div>

<div class='slide'>
  <!-- _S9SLIDE_ -->
<h1 id="今後の課題">今後の課題</h1>
<ul>
  <li>本研究では CbC を用いた Code Gear と Data Gear を持つ Gears OS の記述を行なった。</li>
  <li>また、Gears OS の記述に必要な Meta の生成を行う perl スクリプトの作成を行なった。</li>
  <li>これにより Gears OS のコードの煩雑さは改善され、ユーザーは Context への接続を意識する必要がなくなった。</li>
  <li>今後の課題は、今回 perl スクリプトによって Context や stub を含むファイルの生成を行なったが、LLVM/clang 上で実装しコンパイラから直接 CbC を実行できるようにすることを目的とする。</li>
  <li>また、xv6 を Gears OS での書き換えや、継続ではスタックは積まないため、スタックトレースを使わない手法でのデバッグの考案などもある。</li>
</ul>

<p><a href="プロシン発表時間 セッション7 1/21 10:40 - 12:00"></a></p>

</div>


</div><!-- presentation -->
</body>
</html>
author	ichikitakahiro <e165713@ie.u-ryukyu.ac.jp>
date	Sat, 25 May 2019 15:44:23 +0900
parents	2b71bf2c73c9
children	3e0a1680ae59