读论文CloneCloud Elastic Execution between Mobile Device and Cloud

论文的大致思想：CloneCloud系统，能够自动将手机上的应用传送到云端加速。使用静态分析（static analysis）及动态分割（dynamic profiling）的方法将手机上的而应用程序进行划分。手机中的应用在某个迁移点时，以thread为单位迁移到云端，云端执行结束后返回，重新整合回手机设备上。

这个系统的两点好处：1.能够在不修改手机应用的前提下，通过把一些合适的负载
4000
扔到云端的clone device去执行，来达到省电、优化执行时间的目的。

2.能够让程序员不去考虑 application partitioning的事情。CC的目标就是让应用的partition实现自动化与无缝衔接。

我的关注重点在于线程的迁移，所以如何partition的我就略过了。

文章中有关迁移的示意图如下（文章中的原图）

主要包含三个部分：Migrator，Node Manager,Partitions.

迁移的过程就是当应用线程执行到迁移点（migrant point）时，thread migrator收集thead的状态信息，由于migrator是native thread 与migrant thread在同一地址空间，but outside the virtual machine，所以可以看到native process和virtualized 的状态。

捕获到的信息必须可移植到不同的指令集架构上。所以object field values是以network byte ooder存储的，保证不同处理器架构之间可以适应。另外堆栈中指向需要执行的类中的方法的指针通常是不portable的，所以用其他方式存放class name和method name。

在他们设计的原型中，被迁移的状态在手机VM上做了标记。 Remaining thread继续运行，如果要access这些被标记的状态，那么就会block 直到被迁移的线程返回。

migrator收集全部的信息后发给Node Manager来进行数据传输。

Clone device接收到全部的状态后，把他传给migrator，migrator将context放到一片新的地址空间，来继续执行migrant thread。过程与上面描述的相反。

当migrant thread执行到reintegration point时，就表示他要迁移回移动设备上了。基本与迁移到clone device的过程相同：收集thread state，发送给node manager，然后传送到移动设备，将状态信息给migrator用以恢复。这里有一点不同，从mobile->clone device的状态只需要在clone端新建，而从clone device到mobile device的状态，需要对mobile端的原状态进行更新。即stat
merge。

他们采用了object mapping table来解决这个问题。示意图如下（文章原图）

mobile端发送之前 记录reference（实际是没用的，这里只是说明如何解决reference不同的问题）-MID，CID置为null，发送到clone端之后，clone端进行线程的执行，产生了新的objects，返回之前将之前存在的object添加上CID（CID=11、12），将删除的标记出来（CID=12），将原table中不存在的object添加reference-CID，MID置为null（这里可以看出reference在clone端是与mobile端不同的，CID=14的object重新使用了CID=12的reference，因此不能将其作为object的识别标志。）。发送回mobile端。mobile端接收到MID不是null的，就对应更新，MID是null的就new一个object。

另外使用table还有其他的目的，能够避免传输一些不变的system heap object。

迁移时主要考虑的问题：
1.收集到足够恢复原状态的状态信息
2.在不同的架构上，状态信息的可移植性