\chapter{改善点} \label{chapter:chapter4}
分散フレームワークAliceは、並列環境にも対応したフレームワークである。しかし、並列環境に対応していることを確認するためにbitonic sortを作成、計測したところ、Data Segmentの更新のオーバーヘッドにより、期待した効果を得ることができなかった。また、AliceVNCを開発する際にAliceの送受信部分に無駄なコピーが発見された。
これらを解決するためにAliceに改善を行った。
\section{SEDA Architecture}
SEDA Architecture \cite{cassandra, seda}とはマルチコアスレッドを用いて大量の接続を管理し、受け取ったデータを処理ごとに分けられたステージと呼ばれるスレッドに投げ、処理が終わると次のステージにデータを伝搬させていく処理方式である。
スループット重視のでありレスポンスは多段のパイプラインのせいで遅れてしまう。
Aliceに置いてSEDAを実装するにあたり、データを次のステージにへ伝搬する際、LinkedBlockingQueueを使用している。LinkedBlockingQueueは片方向の連結リストをベースとしたQueue実装である。enqueue / dequeueの操作時の排他制御にはそれぞれ別々のロックオブジェクトが使用されている。そのため、enqueueとdequeueが重なってもロック解除待ちは発生しないが、そのかわりに連結リストのNodeオブジェクトの生成操作などが発生してしまうため、enqueue操作の処理コストが高い。
さらに、非力なマシーンではSEDAの効果を得られず、スレッドを切り替えが頻繁に起こりオーバーヘッドになってしまう。

以上の理由からLocal Data Segmentに対して操作をする際はSEDAを使用せず処理を行なうように変更した。
変更前は、Local Data Segmentに対して操作する場合、putやpeekに沿ったCommandを作成するステージ(Code Segmentが実行されているスレッド)、受け取ったCommandを処理するステージ、Code SegmentにData Segmentをセットするステージ（peekとtakeの場合）の2段または3段のパイプラインで構成されていた。これらを1つのステージにまとめて処理することで、並列環境における性能を向上させた。

\section{Data Segment の再構成（flip 機能の追加）}
Data Segment APIのput、updateを呼ぶとOutput Data Segmentが毎回新しく作成される。そして出力するデータのコピーが行われる。しかし、Input Data Segmentとして取得したデータに変更を行い、Output Data Segmentとして出力する場合、コピーを行なうのは無駄である。そこで、このコピーを減らすことで速度改善を行った。

このコピーを無くし、Data Segmentの更新におけるオーバーヘッドを減らす方法として並列タスク管理フレームワーク Cerium\cite{yutaka:2010a, yutaka:2011a, yutaka:2011b}でも良好な結果を得ているflipを用いた。Ceriumにおけるflipは、Input Data SegmentとOutput Data SegmentをswapさせるAPIである。(ソースコード \ref{src:flipCerium})

\begin{table}[html]
\lstinputlisting[label=src:flipCerium, caption=Ceriumにおけるflip]{source/flip.cc}
\end{table}


\begin{table}[html]
\lstinputlisting[label=src:flipAlice, caption=Aliceにおけるflip]{source/flip.java}
\end{table}

\begin{table}[html]
\lstinputlisting[label=src:exampleFlip,caption=flipの使用例]{source/Sort.java}
\end{table}

Ceriumの場合、Output Data SegmentはTaskが実行された段階ですでに用意されている。そのためデータをOutput Data Segmentに書き込む前にflipを呼ぶ。
Aliceの場合、putまたはupdateを呼んだ段階でOutput Data Segmentが作られるため、ソースコード\ref{src:exampleFlip}のようにInput Data SegmentであるReceiverをflipメソッドに引数として渡すことで、無駄なコピーを減らす。

\section{Data Segmentのデータ表現の追加}
変更前はData Segmentのデータ表現はMessage Pack for JaveのValueオブジェクトのみを用いて表現していた。
Valueオブジェクトとは、Message Packのバイナリにシリアライズできる型のみで構成されたJavaのオブジェクトであり、自己記述形式のデータ形式となっている。そのため、ArrayValueを用いることにより、ユーザーはデータを後からつなげたりすることも可能である。

このValueオブジェクトの特徴の1つに、通信に関わる際のシリアライズ・デシリアライズを高速に行えることがある。
この特徴を用いて、Remote Data Segmentに対する通信の高速化を狙っていた。

しかし、Local Data Segmentに対する通信においては逆効果である。データをLocal Data Segmentに対してputするたびにValue型に変換するコストがかかる。データをpeekする際にもValue型から元の型に変換するというコストがかかる。

この問題を解決するために、一般的なJavaのクラスオブジェクトでもデータ表現を可能にした。Local Data Segmentに対してputする場合は、Valueオブジェクトに変換せず一般的なJavaのクラスオブジェクトのままで、Remote Data Segmentに対してputする場合にのみValueに変換する。これにより、無駄な変換コストを抑えられるようになった。

\section{Data Segmentのデータ表現の変更} \label {subsection:changeDSFormat}
AliceVNCは、\ref {section:AliceVNC}で説明したように、当研究室で開発しているTreeVNCを分散フレームワークAliceを用いて実装した画面共有システムである。

Topology Nodeは受け取った画面データを描画すると同時に、Remote Data Segmentに送信する。Remote Data Segmentに送信する際にはMessage PackによりValue型に変換し、その後シリアライズ化（byteArrayで表現されたバイナリに変換）される。Topology Nodeは受信するとデシリアライズしValue型に変換した後putされる。

このValue型への変換が問題である。受け取ったデータを自分の子ノードに対して送信する際には、デシリアライズしValue型に変換する必要はない。シリアライズ状態のまま子ノードに送信すれば、Value型に変換するオーバーヘッドとValue型をシリアライズするオーバーヘッドを無くすことができる。そこで、Remoteからputされたデータ表現をValue型からbyteArrayで表現されたbinaryに変更した。また、Remoteにputする際にもValue型に変換せずに直接byteArrayに変換するように変換した。


しかし、この変更で新しい問題が発生した。Remoteからputされたデータは必ずbyteArrayで表現される。しかし、putされたbyteArrayが全てシリアライズ化された状態であるとはいえない。一般的なJavaのクラスオブジェクトとしてbyteArrayが使用されている場合が存在する。例えば、AliceVNCで使われる画像データはbyteArrayで表現されているが、これはLocalからputされている。 Input Data Segmentが格納されるReceiverクラスには{\tt asClass()}というメソッドがある。

\begin{itemize}
\item \verb+public <T> T asClass(Class<T> clazz)+
\end{itemize}

このメソッドは取得したデータがRemoteからputされた場合、Value型でなっているためMessage Packを使い適切な型に変換するものである。しかし、byteArray型に変更したため、変換可否を判断することができなくなってしまった。

ここからわかることは、データを表現するにはデータ単体をやりとりするだけでは不十分ということである。変更以前はValue型であるということが状態を表していた。しかし、一般的なJavaのクラスオブジェクトとbyteArrayで表現されたbinaryが混在する現在では、データと一緒にデータの状態を表すメタデータもやりとりする必要がある。そこで、データとデータの状態を1つのオブジェクトにまとめ扱うように変更した。(ソースコード\ref {src:ReceiveData})

\begin{table}[html]
\lstinputlisting[label=src:ReceiveData, caption=データを表現するクラス]{source/ReceiveData.java}
\end{table}

{\tt val}がデータ本体が保存格納される。{\tt serialized}と{\tt byteArray}がデータの状態を表すメタデータである。{\tt serialized}
は、データ本体がシリアライズ化されているかを示す。{\tt byteArray}がデータ本体がbyteArrayであるかを示す。
この2つの状態があることで{\tt asClass()}を使い、適切に変換することができる。(ソースコード\ref {src:asClass})

\begin{table}[html]
\lstinputlisting[label=src:asClass, caption=asClassの処理]{source/asClass.java}
\end{table}

asClassが行う処理は、Localからputされたデータ（{\tt serialized}と{\tt byteArray}がfalseの場合または{\tt byteArray}のみtrueの場合）は、目的のClassにcastする。Remoteからputされたデータ（{\tt serialized}がtrueの場合）はMessage Packを使い変換する。

\subsubsection{Message Packの機能追加}
通信入力部はMessage PackのUnpackerを用いる事により、ストリームを次から次へとデシリアライズすることができる。
しかし、提供されているAPIは全てデシリアライズを行うものであり、シリアライズ状態のオブジェクトを取得することができない。そこでUnpackerにシリアライズ状態のオブジェクトを取得するメソッドを追加した。

\begin{table}[html]
\lstinputlisting[label=src:Incoming, caption=ByteBuffer作成部分]{source/IncomingTcpConnection.java}
\end{table}
ソースコード\ref {src:Incoming} は受け取ったデータをLocal Data Segmentに追加する処理である。
getSerializedByteArrayメソッドでシリアライズ状態のオブジェクトを取得している。

このメソッドの実装をもって、受け取ったデータをデシリアライズせずに、子ノードに渡すことが可能となった。

\section{パケットの再設計}
Aliceの通信の際には、CommandMessage.classのインスタンスをMessage Packによりシリアライズ化したものが送信される。
つまり、CommandMessage.classがパケットの構造を表すものといえる。

\begin{table}[html]
\lstinputlisting[label=src:CommandMessageBefore, caption=変更前のCommandMessage]{source/CommandMessagebefore.java}
\end{table}
ソースコード\ref {src:CommandMessageBefore}が変更前のCommandMessageの内容である。表\ref{tb:variable}はCommandMessageの各変数が何を表しているかを示したものである。
\begin{table}[htbp]
\caption{CommandMessageの変数名の説明}
\label{tb:variable}
\begin{center}
\begin{tabular} {|l|l|}
  \hline
  変数名&説明\\
  \hline
  type&CommandType {\tt PEEK, PUT}などを表す\\
  \hline
  seq&Data Segmentの待ち合わせを行っているCode Segmentを表すunique number\\
  \hline
  key&どのKeyに対して操作を行うか指定する\\
  \hline
  val&データ本体\\
  \hline
  quickFlag&SEDAを挟まずCommandを処理を行うかを示す\\
  \hline
  serialized&データ本体のシリアライズ状態を示す\\
  \hline
\end{tabular}
\end{center}
\end{table}

このパケット構造に問題が存在する。DS本体はCommandMessageがシリアライズ化されるときにはすでに、シリアライズされている。つまり、このままCommandMessageをシリアライズ化を行うと、DS本体をもう1度シリアライズ化を行ってしまう。

\begin{table}[html]
\lstinputlisting[label=src:CommandMessage, caption=変更後のCommandMessage]{source/CommandMessage.java}
\end{table}

そこで、CommandMessageをソースコード\ref{src:CommandMessage}のように変更した。データ本体をCommandMessageのフィールドから外し、後からByteBufferにまとめることにより2度のシリアライズを防ぐ。(ソースコード\ref{src:convert})

\begin{table}[html]
\lstinputlisting[label=src:convert, caption=ByteBuffer作成部分]{source/CreateByteBuffer.java}
\end{table}

この実装ではCommandMessage部をヘッダーとして扱っている。データ部はCommandTypeが{\tt UPDATE、PUT、REPLY}の時のみ後から付加される。以前の実装ではbyte[]の値としてnullを示すNilValueがあるものとしてシリアライズ化されており、これもオーバーヘッドである。現在の実装にでは、CommandTypeが{\tt UPDATE、PUT、REPLY}以外はの時は、データ部をシリアライズ化しないため、nullをシリアライズ化するオーバーヘッドはなくなっている。