[原文出处-------------ART运行时Foreground GC和Background GC切换过程分析](http://blog.csdn.net/luoshengyang/article/details/45301715)
通过前面一系列文章的学习，我们知道了ART运行时既支持Mark-Sweep GC，又支持Compacting GC。其中，Mark-Sweep GC执行效率更高，但是存在内存碎片问题；而Compacting GC执行效率较低，但是不存在内存碎片问题。ART运行时通过引入Foreground GC和Background GC的概念来对这两种GC进行扬长避短。本文就详细分析它们的执行过程以及切换过程。
在前面ART运行时Compacting GC简要介绍和学习计划和ART运行时Compacting GC堆创建过程分析这两篇文章中，我们都有提到了ART运行时的Foreground GC和Background GC。它们是在ART运行时启动通过-Xgc和-XX:BackgroundGC指定的。但是在某同一段时间，ART运行时只会执行Foreground GC或者Background GC。也就是说，Foreground GC和Background GC在整个应用程序的生命周期中是交替执行的。这就涉及到从Foreground GC切换到Background GC，或者从Background GC切换到Foreground GC的问题。
现在两个问题就来了：什么时候执行Foreground GC，什么时候执行Background GC？什么GC作为Foreground GC最合适，什么GC作为Background GC最合适？
顾名思义，Foreground指的就是应用程序在前台运行时，而Background就是应用程序在后台运行时。因此，Foreground GC就是应用程序在前台运行时执行的GC，而Background就是应用程序在后台运行时执行的GC。
应用程序在前台运行时，响应性是最重要的，因此也要求执行的GC是高效的。相反，应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题。因此，Mark-Sweep GC适合作为Foreground GC，而Compacting GC适合作为Background GC。
但是，ART运行时又是怎么知道应用程序目前是运行在前台还是后台呢？这就需要负责管理应用程序组件的系统服务ActivityManagerService闪亮登场了。因为ActivityManagerService清楚地知道应用程序的每一个组件的运行状态，也就是它们当前是在前台运行还是后台运行，从而得到应用程序是前台运行还是后台运行的结论。
我们通过图1来描述应用程序的运行状态与Foreground GC和Background GC的时序关系，如下所示：
图1 应用程序运行状态与Foreground GC和Background GC的时序关系
从图1还可以看到，当从Foreground GC切换到Background GC，或者从Background GC切换到Foreground GC，会发生一次Compacting GC的行为。这是由于Foreground GC和Background GC的底层堆空间结构是一样的，因此发生Foreground GC和Background GC切换时，需要将当前存活的对象从一个Space转移到另外一个Space上去。这个刚好就是Semi-Space GC和Generational Semi-Space GC合适干的事情。
图1中的显示了应用程序的两个状态：kProcessStateJankPerceptible和kProcessStateJankImperceptible。其中，kProcessStateJankPerceptible说的就是应用程序处于用户可感知的状态，这就相当于是前台状态；而kProcessStateJankImperceptible说的就是应用程序处于用户不可感知的状态，这就相当于是后台状态。
接下来，我们就结合ActivityManagerService来分析Foreground GC和Background GC的切换过程。
从前面[Android应用程序的Activity启动过程简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/6685853)这个系列的文章可以知道，应用程序组件是通过ActivityManagerService进行启动的。例如，当我们从Launcher启动一个应用程序时，实际的是在这个应用程序中Action和Category分别被配置为MAIN和LAUNCHER的Activity。这个Activity最终由ActivityManagerService通知其所在的进程进行启动工作的，也就是通过ApplicationThread类的成员函数scheduleLaunchActivity开始执行启动工作的。其它类型的组件的启动过程也是类似的，这里我们仅以Activity的启动过程作为示例，来说明ART运行时如何知道要进行Foreground GC和Background GC切换的。
ApplicationThread类的成员函数scheduleLaunchActivity的实现如下所示：
~~~
public final class ActivityThread {
......
private class ApplicationThread extends ApplicationThreadNative {
......
public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,
ActivityInfo info, Configuration curConfig, CompatibilityInfo compatInfo,
IVoiceInteractor voiceInteractor, int procState, Bundle state,
PersistableBundle persistentState, List<ResultInfo> pendingResults,
List<Intent> pendingNewIntents, boolean notResumed, boolean isForward,
ProfilerInfo profilerInfo) {
updateProcessState(procState, false);
ActivityClientRecord r = new ActivityClientRecord();
r.token = token;
r.ident = ident;
r.intent = intent;
r.voiceInteractor = voiceInteractor;
r.activityInfo = info;
r.compatInfo = compatInfo;
r.state = state;
r.persistentState = persistentState;
r.pendingResults = pendingResults;
r.pendingIntents = pendingNewIntents;
r.startsNotResumed = notResumed;
r.isForward = isForward;
r.profilerInfo = profilerInfo;
updatePendingConfiguration(curConfig);
sendMessage(H.LAUNCH_ACTIVITY, r);
}
......
}
......
}
~~~
这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。
ApplicationThread类的成员函数scheduleLaunchActivity首先是调用另外一个成员函数updateProcessState更新进程的当前状态，接着再将其余参数封装在一个ActivityClientRecord对象中，并且将这个ActivityClientRecord对象通过一个H.LAUNCH_ACTIVITY消息传递给应用程序主线程处理。应用程序主线程处理对这个消息的处理就是启动指定的Activity，这个过程可以参考前面[Android应用程序的Activity启动过程简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/6685853)这个系列的文章。ApplicationThread类的成员函数scheduleLaunchActivity还调用了另外一个成员函数updatePendingConfiguration将参数curConfig描述的系统当前配置信息保存下来待后面处理。
我们主要关注ApplicationThread类的成员函数updateProcessState，因为它涉及到进程状态的更新，它的实现如下所示：
~~~
public final class ActivityThread {
......
private class ApplicationThread extends ApplicationThreadNative {
......
public void updateProcessState(int processState, boolean fromIpc) {
synchronized (this) {
if (mLastProcessState != processState) {
mLastProcessState = processState;
// Update Dalvik state based on ActivityManager.PROCESS_STATE_* constants.
final int DALVIK_PROCESS_STATE_JANK_PERCEPTIBLE = 0;
final int DALVIK_PROCESS_STATE_JANK_IMPERCEPTIBLE = 1;
int dalvikProcessState = DALVIK_PROCESS_STATE_JANK_IMPERCEPTIBLE;
// TODO: Tune this since things like gmail sync are important background but not jank perceptible.
if (processState <= ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND) {
dalvikProcessState = DALVIK_PROCESS_STATE_JANK_PERCEPTIBLE;
}
VMRuntime.getRuntime().updateProcessState(dalvikProcessState);
......
}
}
}
......
}
......
}
~~~
这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。
ApplicationThread类的成员变量mLastProcessState描述的是进程上一次的状态，而参数processState描述的是进程当前的状态。当这两者的值不一致时，就表明进程的状态发生了变化，这时候就需要调用VMRuntime类的成员函数updateProcessState通知ART运行时，以便ART运行时可以在Foreground GC和Background GC之间切换。
ActivityManagerService一共定义了14种进程状态，如下所示：
~~~
public class ActivityManager {
......
/** @hide Process is a persistent system process. */
public static final int PROCESS_STATE_PERSISTENT = 0;
/** @hide Process is a persistent system process and is doing UI. */
public static final int PROCESS_STATE_PERSISTENT_UI = 1;
/** @hide Process is hosting the current top activities. Note that this covers
* all activities that are visible to the user. */
public static final int PROCESS_STATE_TOP = 2;
/** @hide Process is important to the user, and something they are aware of. */
public static final int PROCESS_STATE_IMPORTANT_FOREGROUND = 3;
/** @hide Process is important to the user, but not something they are aware of. */
public static final int PROCESS_STATE_IMPORTANT_BACKGROUND = 4;
/** @hide Process is in the background running a backup/restore operation. */
public static final int PROCESS_STATE_BACKUP = 5;
/** @hide Process is in the background, but it can't restore its state so we want
* to try to avoid killing it. */
public static final int PROCESS_STATE_HEAVY_WEIGHT = 6;
/** @hide Process is in the background running a service. Unlike oom_adj, this level
* is used for both the normal running in background state and the executing
* operations state. */
public static final int PROCESS_STATE_SERVICE = 7;
/** @hide Process is in the background running a receiver. Note that from the
* perspective of oom_adj receivers run at a higher foreground level, but for our
* prioritization here that is not necessary and putting them below services means
* many fewer changes in some process states as they receive broadcasts. */
public static final int PROCESS_STATE_RECEIVER = 8;
/** @hide Process is in the background but hosts the home activity. */
public static final int PROCESS_STATE_HOME = 9;
/** @hide Process is in the background but hosts the last shown activity. */
public static final int PROCESS_STATE_LAST_ACTIVITY = 10;
/** @hide Process is being cached for later use and contains activities. */
public static final int PROCESS_STATE_CACHED_ACTIVITY = 11;
/** @hide Process is being cached for later use and is a client of another cached
* process that contains activities. */
public static final int PROCESS_STATE_CACHED_ACTIVITY_CLIENT = 12;
/** @hide Process is being cached for later use and is empty. */
public static final int PROCESS_STATE_CACHED_EMPTY = 13;
......
}
~~~
这些进程状态值定义在文件frameworks/base/core/java/android/app/ActivityManager.java。
每一个进程状态都通过一个整数来描述，其中，值越小就表示进程越重要。ART运行时将状态值大于等于PROCESS_STATE_IMPORTANT_FOREGROUND的进程都认为是用户可感知的，也就是前台进程，其余的进程则认为是用户不可感知的，也就是后台进程。通过这种方式，ApplicationThread类的成员函数updateProcessState就可以简化ART运行时对进程状态的处理。
除了上述的Activity的Launch启动生命周期函数被ActivityManagerService通知调用时，Activity的Resume生命周期函数被ActivityManagerService通知调用调用时，也会发生类似的通过VMRuntime类的成员函数updateProcessState通知ART运行时应用程序状态发生了改变。对于其它的组件，例如Broadcast Receiver组件被触发时，Service组件被创建以及被绑定时，也会通过VMRuntime类的成员函数updateProcessState通知ART运行时应用程序状态发生了改变。
不过，上述组件的生命周期对应的都是应用程序处于前台时的情况，也就是要求ART运行时从Background GC切换为Foreground GC的情况。当应用程序处于后台时，ActivityManagerService是通过直接设置应用程序的状态来通知ART运行时应用程序状态发生了改变的。
ApplicationThread类实现了一个Binder接口setProcessState，供ActivityManagerService直接设置应用程序的状态，它的实现如下所示：
~~~
public final class ActivityThread {
......
private class ApplicationThread extends ApplicationThreadNative {
......
public void setProcessState(int state) {
updateProcessState(state, true);
}
......
}
......
}
~~~
这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。
ApplicationThread类实现的Binder接口setProcessState也是通过上面分析的成员函数updateProcessState来通知ART运行时进程状态发生了改变的。不过这时候进程的状态就有可能是从前面进程变为后台进程，例如当运行在该进程的Activity组件处理Stop状态时。
接下来我们继续分析VMRuntime类的成员函数updateProcessState的实现，以便了解ART运行时执行Foreground GC和Background GC切换的过程，如下所示：
~~~
public final class VMRuntime {
......
/**
* Let the heap know of the new process state. This can change allocation and garbage collection
* behavior regarding trimming and compaction.
*/
public native void updateProcessState(int state);
......
}
~~~
这个函数定义在文件libcore/libart/src/main/java/dalvik/system/VMRuntime.java中。
VMRuntime类的成员函数updateProcessState是一个Native函数，它由C++层的函数VMRuntime_updateProcessState实现，如下所示：
~~~
static void VMRuntime_updateProcessState(JNIEnv* env, jobject, jint process_state) {
Runtime::Current()->GetHeap()->UpdateProcessState(static_cast<gc::ProcessState>(process_state));
......
}
~~~
这个函数定义在文件art/runtime/native/dalvik_system_VMRuntime.cc中。
函数VMRuntime_updateProcessState主要是调用了Heap类的成员函数UpdateProcessState来通知ART运行时切换Foreground GC和Background GC，后者的实现如下所示：
~~~
void Heap::UpdateProcessState(ProcessState process_state) {
if (process_state_ != process_state) {
process_state_ = process_state;
......
if (process_state_ == kProcessStateJankPerceptible) {
// Transition back to foreground right away to prevent jank.
RequestCollectorTransition(foreground_collector_type_, 0);
} else {
// Don't delay for debug builds since we may want to stress test the GC.
// If background_collector_type_ is kCollectorTypeHomogeneousSpaceCompact then we have
// special handling which does a homogenous space compaction once but then doesn't transition
// the collector.
RequestCollectorTransition(background_collector_type_,
kIsDebugBuild ? 0 : kCollectorTransitionWait);
}
}
}
~~~
这个函数定义在文件art/runtime/gc/heap.cc中。
Heap类的成员变量process_state_记录了进程上一次的状态，参数process_state描述进程当前的状态。当这两者的值不相等的时候，就说明进程状态发生了变化。
如果是从kProcessStateJankImperceptible状态变为kProcessStateJankPerceptible状态，那么就调用Heap类的成员函数RequestCollectorTransition请求马上将当前的GC设置为Foreground GC。
如果是从kProcessStateJankPerceptible状态变为kProcessStateJankImperceptible，那么就调用Heap类的成员函数RequestCollectorTransition请求将当前的GC设置为Background GC。注意，在这种情况下，对于非DEBUG版本的ART运行时，不是马上将当前的GC设置为Background GC的，而是指定在kCollectorTransitionWait（5秒）时间后再设置。这样使得进程进入后台运行的一小段时间内，仍然可以使用效率较高的Mark-Sweep GC。
Heap类的成员函数RequestCollectorTransition的实现如下所示：
~~~
void Heap::RequestCollectorTransition(CollectorType desired_collector_type, uint64_t delta_time) {
Thread* self = Thread::Current();
{
MutexLock mu(self, *heap_trim_request_lock_);
if (desired_collector_type_ == desired_collector_type) {
return;
}
heap_transition_or_trim_target_time_ =
std::max(heap_transition_or_trim_target_time_, NanoTime() + delta_time);
desired_collector_type_ = desired_collector_type;
}
SignalHeapTrimDaemon(self);
}
~~~
这个函数定义在文件art/runtime/gc/heap.cc中。
Heap类的成员函数RequestCollectorTransition首先将要切换至的目标GC以及时间点记录在成员变量desired_collector_type_和heap_transition_or_trim_target_time_中，接着再调用另外一个成员函数SignalHeapTrimDaemon唤醒一个Heap Trimmer守护线程来执行GC切换操作。注意，如果上一次请求的GC切换还未执行，又请求了下一次GC切换，并且下一次GC切换指定的时间大于上一次指定的时间，那么上次请求的GC切换就会被取消。
Heap类的成员函数RequestCollectorTransition的实现如下所示：
~~~
void Heap::SignalHeapTrimDaemon(Thread* self) {
JNIEnv* env = self->GetJniEnv();
DCHECK(WellKnownClasses::java_lang_Daemons != nullptr);
DCHECK(WellKnownClasses::java_lang_Daemons_requestHeapTrim != nullptr);
env->CallStaticVoidMethod(WellKnownClasses::java_lang_Daemons,
WellKnownClasses::java_lang_Daemons_requestHeapTrim);
CHECK(!env->ExceptionCheck());
}
~~~
这个函数定义在文件art/runtime/gc/heap.cc中。
Heap类的成员函数RequestCollectorTransition通过JNI接口调用了Daemons类的静态成员函数requestHeapTrim请求执行一次GC切换操作。
Daemons类的静态成员函数requestHeapTrim的实现如下所示：
~~~
public final class Daemons {
......
public static void requestHeapTrim() {
synchronized (HeapTrimmerDaemon.INSTANCE) {
HeapTrimmerDaemon.INSTANCE.notify();
}
}
......
}
~~~
这个函数定义在文件libcore/libart/src/main/java/java/lang/Daemons.java中。
在前面[ART运行时垃圾收集（GC）过程分析](http://blog.csdn.net/luoshengyang/article/details/42555483)一文中提到，Java层的java.lang.Daemons类在加载的时候，会启动五个与堆或者GC相关的守护线程，其中一个守护线程就是HeapTrimmerDaemon，这里通过调用它的成员函数notify来唤醒它。
HeapTrimmerDaemon原先被Blocked在成员函数run中，当它被唤醒之后 ，就会继续执行它的成员函数run，如下所示：
~~~
public final class Daemons {
......
private static class HeapTrimmerDaemon extends Daemon {
private static final HeapTrimmerDaemon INSTANCE = new HeapTrimmerDaemon();
@Override public void run() {
while (isRunning()) {
try {
synchronized (this) {
wait();
}
VMRuntime.getRuntime().trimHeap();
} catch (InterruptedException ignored) {
}
}
}
}
......
}
~~~
这个函数定义在文件libcore/libart/src/main/java/java/lang/Daemons.java中。
从这里就可以看到，HeapTrimmerDaemon被唤醒之后，就会调用VMRuntime类的成员函数trimHeap来执行GC切换操作。
VMRuntime类的成员函数trimHeap是一个Native函数，由C++层的函数VMRuntime_trimHeap实现，如下所示：
~~~
static void VMRuntime_trimHeap(JNIEnv*, jobject) {
Runtime::Current()->GetHeap()->DoPendingTransitionOrTrim();
}
~~~
这个函数定义在文件art/runtime/native/dalvik_system_VMRuntime.cc 。
函数VMRuntime_trimHeap又是通过调用Heap类的成员函数DoPendingTransitionOrTrim来执行GC切换操作的，如下所示：
~~~
void Heap::DoPendingTransitionOrTrim() {
Thread* self = Thread::Current();
CollectorType desired_collector_type;
// Wait until we reach the desired transition time.
while (true) {
uint64_t wait_time;
{
MutexLock mu(self, *heap_trim_request_lock_);
desired_collector_type = desired_collector_type_;
uint64_t current_time = NanoTime();
if (current_time >= heap_transition_or_trim_target_time_) {
break;
}
wait_time = heap_transition_or_trim_target_time_ - current_time;
}
ScopedThreadStateChange tsc(self, kSleeping);
usleep(wait_time / 1000); // Usleep takes microseconds.
}
// Launch homogeneous space compaction if it is desired.
if (desired_collector_type == kCollectorTypeHomogeneousSpaceCompact) {
if (!CareAboutPauseTimes()) {
PerformHomogeneousSpaceCompact();
}
// No need to Trim(). Homogeneous space compaction may free more virtual and physical memory.
desired_collector_type = collector_type_;
return;
}
// Transition the collector if the desired collector type is not the same as the current
// collector type.
TransitionCollector(desired_collector_type);
......
// Do a heap trim if it is needed.
Trim();
}
~~~
这个函数定义在文件art/runtime/gc/heap.cc中。
前面提到，下一次GC切换时间记录在Heap类的成员变量heap_transition_or_trim_target_time_中，因此，Heap类的成员函数DoPendingTransitionOrTrim首先是看看当前时间是否已经达到指定的GC切换时间。如果还没有达到，那么就进行等待，直到时间到达为止。
有一种特殊情况，如果要切换至的GC是kCollectorTypeHomogeneousSpaceCompact，并且Heap类的成员函数CareAboutPauseTimes表明不在乎执行HomogeneousSpaceCompact GC带来的暂停时间，那么就会调用Heap类的成员函数PerformHomogeneousSpaceCompact执行一次同构空间压缩。Heap类的成员函数PerformHomogeneousSpaceCompact执行同构空间压缩的过程，可以参考前面[ART运行时Compacting GC为新创建对象分配内存的过程分析](http://blog.csdn.net/luoshengyang/article/details/44910271)一文。
Heap类的成员函数CareAboutPauseTimes实际上是判断进程的当前状态是否是用户可感知的，即是否等于kProcessStateJankPerceptible。如果是的话，就说明它在乎GC执行时带来的暂停时间。它的实现如下所示：
~~~
class Heap {
public:
......
// Returns true if we currently care about pause times.
bool CareAboutPauseTimes() const {
return process_state_ == kProcessStateJankPerceptible;
}
......
};
~~~
这个函数定义在文件art/runtime/gc/heap.h中。
回到Heap类的成员函数DoPendingTransitionOrTrim中，我们继续讨论要切换至的GC是kCollectorTypeHomogeneousSpaceCompact的情况。如果Heap类的成员函数CareAboutPauseTimes表明在乎执行HomogeneousSpaceCompact GC带来的暂停时间，那么就不会调用Heap类的成员函数PerformHomogeneousSpaceCompact执行同构空间压缩。
只要切换至的GC是kCollectorTypeHomogeneousSpaceCompact，无论上述的哪一种情况，都不会真正执行GC切换的操作，因此这时候Heap类的成员函数DoPendingTransitionOrTrim就可以返回了。
从前面的调用过程可以知道，要切换至的GC要么是Foreground GC，要么是Background GC。一般来说，我们是不会将Foreground GC设置为HomogeneousSpaceCompact GC的，但是却有可能将Background GC设置为HomogeneousSpaceCompact GC。因此，上述讨论的情况只发生在Foreground GC切换为Background GC的时候。
另一方面，如果要切换至的GC不是kCollectorTypeHomogeneousSpaceCompact，那么Heap类的成员函数DoPendingTransitionOrTrim就会调用另外一个成员函数TransitionCollector执行切换GC操作。一旦GC切换完毕，Heap类的成员函数DoPendingTransitionOrTrim还会调用成员函数Trim对当前ART运行时堆进行裁剪，也就是将现在没有使用到的内存归还给内核。这个过程可以参考前面[ART运行时垃圾收集（GC）过程分析](http://blog.csdn.net/luoshengyang/article/details/42555483)一文。
接下来我们继续分析Heap类的成员函数TransitionCollector的实现，以便了解GC的切换过程，如下所示：
~~~
void Heap::TransitionCollector(CollectorType collector_type) {
if (collector_type == collector_type_) {
return;
}
......
ThreadList* const tl = runtime->GetThreadList();
......
// Busy wait until we can GC (StartGC can fail if we have a non-zero
// compacting_gc_disable_count_, this should rarely occurs).
for (;;) {
{
ScopedThreadStateChange tsc(self, kWaitingForGcToComplete);
MutexLock mu(self, *gc_complete_lock_);
// Ensure there is only one GC at a time.
WaitForGcToCompleteLocked(kGcCauseCollectorTransition, self);
// Currently we only need a heap transition if we switch from a moving collector to a
// non-moving one, or visa versa.
const bool copying_transition = IsMovingGc(collector_type_) != IsMovingGc(collector_type);
// If someone else beat us to it and changed the collector before we could, exit.
// This is safe to do before the suspend all since we set the collector_type_running_ before
// we exit the loop. If another thread attempts to do the heap transition before we exit,
// then it would get blocked on WaitForGcToCompleteLocked.
if (collector_type == collector_type_) {
return;
}
// GC can be disabled if someone has a used GetPrimitiveArrayCritical but not yet released.
if (!copying_transition || disable_moving_gc_count_ == 0) {
// TODO: Not hard code in semi-space collector?
collector_type_running_ = copying_transition ? kCollectorTypeSS : collector_type;
break;
}
}
usleep(1000);
}
tl->SuspendAll();
switch (collector_type) {
case kCollectorTypeSS: {
if (!IsMovingGc(collector_type_)) {
// Create the bump pointer space from the backup space.
......
std::unique_ptr<MemMap> mem_map(main_space_backup_->ReleaseMemMap());
// We are transitioning from non moving GC -> moving GC, since we copied from the bump
// pointer space last transition it will be protected.
.....
mem_map->Protect(PROT_READ | PROT_WRITE);
bump_pointer_space_ = space::BumpPointerSpace::CreateFromMemMap("Bump pointer space",
mem_map.release());
AddSpace(bump_pointer_space_);
Compact(bump_pointer_space_, main_space_, kGcCauseCollectorTransition);
// Use the now empty main space mem map for the bump pointer temp space.
mem_map.reset(main_space_->ReleaseMemMap());
// Unset the pointers just in case.
if (dlmalloc_space_ == main_space_) {
dlmalloc_space_ = nullptr;
} else if (rosalloc_space_ == main_space_) {
rosalloc_space_ = nullptr;
}
// Remove the main space so that we don't try to trim it, this doens't work for debug
// builds since RosAlloc attempts to read the magic number from a protected page.
RemoveSpace(main_space_);
RemoveRememberedSet(main_space_);
delete main_space_; // Delete the space since it has been removed.
main_space_ = nullptr;
RemoveRememberedSet(main_space_backup_.get());
main_space_backup_.reset(nullptr); // Deletes the space.
temp_space_ = space::BumpPointerSpace::CreateFromMemMap("Bump pointer space 2",
mem_map.release());
AddSpace(temp_space_);
}
break;
}
case kCollectorTypeMS:
// Fall through.
case kCollectorTypeCMS: {
if (IsMovingGc(collector_type_)) {
......
std::unique_ptr<MemMap> mem_map(temp_space_->ReleaseMemMap());
RemoveSpace(temp_space_);
temp_space_ = nullptr;
mem_map->Protect(PROT_READ | PROT_WRITE);
CreateMainMallocSpace(mem_map.get(), kDefaultInitialSize, mem_map->Size(),
mem_map->Size());
mem_map.release();
// Compact to the main space from the bump pointer space, don't need to swap semispaces.
AddSpace(main_space_);
Compact(main_space_, bump_pointer_space_, kGcCauseCollectorTransition);
mem_map.reset(bump_pointer_space_->ReleaseMemMap());
RemoveSpace(bump_pointer_space_);
bump_pointer_space_ = nullptr;
const char* name = kUseRosAlloc ? kRosAllocSpaceName[1] : kDlMallocSpaceName[1];
......
main_space_backup_.reset(CreateMallocSpaceFromMemMap(mem_map.get(), kDefaultInitialSize,
mem_map->Size(), mem_map->Size(),
name, true));
......
mem_map.release();
}
break;
}
default: {
......
break;
}
ChangeCollector(collector_type);
tl->ResumeAll();
......
}
~~~
这个函数定义在文件art/runtime/gc/heap.h中。
Heap类的成员函数TransitionCollector首先判断ART运行时当前使用的GC与要切换至的GC是一样的，那么就什么也不用做就返回了。
另一方面，如果ART运行时当前使用的GC与要切换至的GC是不一样的，那么接下来就要将ART运行时当前使用的GC切换至参数collector_type描述的GC了。由于将GC切换是通过执行一次Semi-Space GC或者Generational Semi-Space GC来实现的，因此Heap类的成员函数TransitionCollector在继续往下执行之前，要先调用Heap类的成员函数WaitForGcToCompleteLocked判断当前是否有GC正在执行。如果有的话，就进行等待，直到对应的GC执行完为止。
注意，有可能当前正在执行的GC就是要切换至的GC，在这种情况下，就没有必要将当前使用的GC切换为参数collector_type描述的GC了。此外，只有从当前执行的GC和要切换至的GC不同时为Compacting GC或者Mark-Sweep GC的时候，Heap类的成员函数TransitionCollector才会真正执行切换的操作。换句话说，只有从Compacting GC切换为Mark-Sweep GC或者从Mark-Sweep GC切换为Compacting GC时，Heap类的成员函数TransitionCollector才会真正执行切换的操作。但是，如果这时候ART运行时被禁止执行Compacting GC，即Heap类的成员函数disable_moving_gc_count_不等于0，那么Heap类的成员函数TransitionCollector就需要继续等待，直到ART运行时重新允许执行Compacting GC为止。这是因为接下来的GC切换操作是通过执行一次Compacting GC来实现的。
接下来的GC切换操作是通过调用Heap类的成员函数Compact来实现的。关于Heap类的成员函数Compact，我们在前面[ART运行时Compacting GC为新创建对象分配内存的过程分析](http://blog.csdn.net/luoshengyang/article/details/44910271)一文已经分析过了，它主要通过执行一次Semi-Space GC、Generational Semi-Space GC或者Mark-Compact GC将指定的Source Space上的存活对象移动至指定的Target Space中。如果Source Space与Target Space相同，那么执行的就是Mark-Compact GC，否则就是Semi-Space GC或者Generational Semi-Space GC。由于Heap类的成员函数Compact是需要在Stop-the-world的前提下执行的，因此在调用它的前后，需要执行挂起和恢复除当前正在执行的线程之外的所有ART运行时线程。
Heap类的成员函数TransitionCollector通过switch语句来确定需要传递给成员函数Compact的Source Space和Target Space。通过这个switch语句，我们也可以更清楚看到Heap类的成员函数TransitionCollector允许从什么GC切换至什么GC。
首先，可切换至的GC只有三种，分别为Semi-Space GC、Mark-Sweep GC和Concurrent Mark-Sweep GC。其中，当要切换至的GC为Mark-Sweep GC和Concurrent Mark-Sweep GC时，它们的切换过程是一样的。因此，接下来我们就分两种情况来讨论。
第一种情况是要切换至的GC为Semi-Space GC。根据我们前面的分析，这时候原来的GC只能为Mark-Sweep GC或者Concurrent Mark-Sweep GC。否则的话，就不需要执行GC切换操作。从前面[ART运行时Compacting GC堆创建过程分析](http://blog.csdn.net/luoshengyang/article/details/44789295)一文可以知道，当原来的GC为Mark-Sweep GC或者Concurrent Mark-Sweep GC时，ART运行时堆由Image Space、Zygote Space、Non Moving Space、Main Space、Main Backup Space和Large Object Space组成。这时候要做的是将Main Space上的存活对象移动至一个新创建的Bump Pointer Space上去。也就是说，这时候的Source Space为Main Space，而Target Space为Bump Pointer Space。
Main Space就保存在Heap类的成员变量main_space_中，因此就很容易可以获得。但是这时候是没有现成的Bump Pointer Space的，因此就需要创建一个。由于这时候的Main Backup Space是闲置的，并且当GC切换完毕，它也用不上了，因此我们就可以将Main Backup Space底层使用的内存块获取回来，然后再封装成一个Bump Pointer Space。注意，这时候创建的Bump Pointer Space也是作为GC切换完成后的Semi-Space GC的From Space使用的，因此，除了要将它保存在Heap类的成员变量bump_pointer_space_之外，还要将它添加到ART运行时堆的Space列表中去。
这时候Source Space和Target Space均已准备完毕，因此就可以执行Heap类的成员函数Compact了。执行完毕，还需要做一系列的清理工作，包括：
1. 删除Main Space及其关联的Remembered Set。从前面[ART运行时Compacting GC堆创建过程分析](http://blog.csdn.net/luoshengyang/article/details/44789295)一文可以知道，Heap类的成员变量dlmalloc_space_和rosalloc_space_指向的都是Main Space。既然现在Main Space要被删除了，因此就需要将它们设置为nullptr。
2. 删除Main Backup Space及其关联的Remembered Set。
3. 创建一个Bump Pointer Space保存在Heap类的成员变量temp_space_中，作为GC切换完成后的Semi-Space GC的To Space使用。注意，这个To Space底层使用的内存块是来自于原来的Main Space的。
这意味着将从Mark-Sweep GC或者Concurrent Mark-Sweep GC切换为Semi-Space GC之后，原来的Main Space和Main Backup Space就消失了，并且多了两个Bump Pointer Space，其中一个作为From Space，另外一个作为To Space，并且From Space上的对象来自于原来的Main Space的存活对象。
第二种情况是要切换至Mark-Sweep GC或者Concurrent Mark-Sweep GC。根据我们前面的分析，这时候原来的GC只能为Semi-Space GC、Generational Semi-Space GC或者Mark-Compact GC。否则的话，就不需要执行GC切换操作。从前面[ART运行时Compacting GC堆创建过程分析](http://blog.csdn.net/luoshengyang/article/details/44789295)一文可以知道，当原来的GC为Semi-Space GC、Generational Semi-Space GC或者Mark-Compact GC时，ART运行时堆由Image Space、Zygote Space、Non Moving Space、Bump Pointer Space、Temp Space和Large Object Space组成。这时候要做的是将Bump Pointer Space上的存活对象移动至一个新创建的Main Space上去。也就是说，这时候的Source Space为Bump Pointer Space，而Target Space为Main Space。
Bump Pointer Space就保存在Heap类的成员变量bump_pointer_space_中，因此就很容易可以获得。但是这时候是没有现成的Main Space的，因此就需要创建一个。由于这时候的Temp Space是闲置的，并且当GC切换完毕，它也用不上了，因此我们就可以将Temp Space底层使用的内存块获取回来，然后再封装成一个Main Space，这是通过调用Heap类的成员函数CreateMainMallocSpace来实现的。注意，Heap类的成员函数CreateMainMallocSpace在执行的过程中，会将创建的Main Space保存在Heap类的成员变量main_space_中，并且它也是作为GC切换完成后的Mark-Sweep GC或者Concurrent Mark-Sweep GC的Main Space使用的，因此，就还要将它添加到ART运行时堆的Space列表中去。
这时候Source Space和Target Space均已准备完毕，因此就可以执行Heap类的成员函数Compact了。执行完毕，还需要做一系列的清理工作，包括：
1. 删除Bump Pointer Space。
2. 删除Temp Space。
3. 创建一个Main Backup Space，保存在Heap类的成员变量main_space_backup_中，这是通过调用Heap类的成员函数CreateMallocSpaceFromMemMap实现的，并且该Main Backup Space底层使用的内存块是来自于原来的Bump Pointer Space的。
这样，GC切换的操作就基本执行完毕，最后还需要做的一件事情是调用Heap类的成员函数ChangeCollector记录当前使用的GC，以及相应地调整当前可用的内存分配器。这个函数的具体实现可以参考前面[ART运行时Compacting GC为新创建对象分配内存的过程分析](http://blog.csdn.net/luoshengyang/article/details/44910271)一文。
至此，ART运行时Foreground GC和Background GC的切换过程分析就分析完成了，ART运行时引进的Compacting GC的学习计划也完成了，重新学习可以参考ART运行时Compacting GC简要介绍和学习计划一文
- 前言
- Android组件设计思想
- Android源代码开发和调试环境搭建
- Android源代码下载和编译
- Android源代码情景分析法
- Android源代码调试分析法
- 手把手教你为手机编译ROM
- 在Ubuntu上下载、编译和安装Android最新源代码
- 在Ubuntu上下载、编译和安装Android最新内核源代码（Linux Kernel）
- 如何单独编译Android源代码中的模块
- 在Ubuntu上为Android系统编写Linux内核驱动程序
- 在Ubuntu上为Android系统内置C可执行程序测试Linux内核驱动程序
- 在Ubuntu上为Android增加硬件抽象层（HAL）模块访问Linux内核驱动程序
- 在Ubuntu为Android硬件抽象层（HAL）模块编写JNI方法提供Java访问硬件服务接口
- 在Ubuntu上为Android系统的Application Frameworks层增加硬件访问服务
- 在Ubuntu上为Android系统内置Java应用程序测试Application Frameworks层的硬件服务
- Android源代码仓库及其管理工具Repo分析
- Android编译系统简要介绍和学习计划
- Android编译系统环境初始化过程分析
- Android源代码编译命令m/mm/mmm/make分析
- Android系统镜像文件的打包过程分析
- 从CM刷机过程和原理分析Android系统结构
- Android系统架构概述
- Android系统整体架构
- android专用驱动
- Android硬件抽象层HAL
- Android应用程序组件
- Android应用程序框架
- Android用户界面架构
- Android虚拟机之Dalvik虚拟机
- Android硬件抽象层
- Android硬件抽象层（HAL）概要介绍和学习计划
- Android专用驱动
- Android Logger驱动系统
- Android日志系统驱动程序Logger源代码分析
- Android应用程序框架层和系统运行库层日志系统源代码分析
- Android日志系统Logcat源代码简要分析
- Android Binder驱动系统
- Android进程间通信（IPC）机制Binder简要介绍和学习计划
- 浅谈Service Manager成为Android进程间通信（IPC）机制Binder守护进程之路
- 浅谈Android系统进程间通信（IPC）机制Binder中的Server和Client获得Service Manager接口之路
- Android系统进程间通信（IPC）机制Binder中的Server启动过程源代码分析
- Android系统进程间通信（IPC）机制Binder中的Client获得Server远程接口过程源代码分析
- Android系统进程间通信Binder机制在应用程序框架层的Java接口源代码分析
- Android Ashmem驱动系统
- Android系统匿名共享内存Ashmem（Anonymous Shared Memory）简要介绍和学习计划
- Android系统匿名共享内存Ashmem（Anonymous Shared Memory）驱动程序源代码分析
- Android系统匿名共享内存Ashmem（Anonymous Shared Memory）在进程间共享的原理分析
- Android系统匿名共享内存（Anonymous Shared Memory）C++调用接口分析
- Android应用程序进程管理
- Android应用程序进程启动过程的源代码分析
- Android系统进程Zygote启动过程的源代码分析
- Android系统默认Home应用程序（Launcher）的启动过程源代码分析
- Android应用程序消息机制
- Android应用程序消息处理机制（Looper、Handler）分析
- Android应用程序线程消息循环模型分析
- Android应用程序输入事件分发和处理机制
- Android应用程序键盘（Keyboard）消息处理机制分析
- Android应用程序UI架构
- Android系统的开机画面显示过程分析
- Android帧缓冲区（Frame Buffer）硬件抽象层（HAL）模块Gralloc的实现原理分析
- SurfaceFlinger
- Android系统Surface机制的SurfaceFlinger服务
- SurfaceFlinger服务简要介绍和学习计划
- 启动过程分析
- 对帧缓冲区（Frame Buffer）的管理分析
- 线程模型分析
- 渲染应用程序UI的过程分析
- Android应用程序与SurfaceFlinger服务的关系
- 概述和学习计划
- 连接过程分析
- 共享UI元数据（SharedClient）的创建过程分析
- 创建Surface的过程分析
- 渲染Surface的过程分析
- Android应用程序窗口（Activity）
- 实现框架简要介绍和学习计划
- 运行上下文环境（Context）的创建过程分析
- 窗口对象（Window）的创建过程分析
- 视图对象（View）的创建过程分析
- 与WindowManagerService服务的连接过程分析
- 绘图表面（Surface）的创建过程分析
- 测量（Measure）、布局（Layout）和绘制（Draw）过程分析
- WindowManagerService
- WindowManagerService的简要介绍和学习计划
- 计算Activity窗口大小的过程分析
- 对窗口的组织方式分析
- 对输入法窗口（Input Method Window）的管理分析
- 对壁纸窗口（Wallpaper Window）的管理分析
- 计算窗口Z轴位置的过程分析
- 显示Activity组件的启动窗口（Starting Window）的过程分析
- 切换Activity窗口（App Transition）的过程分析
- 显示窗口动画的原理分析
- Android控件TextView的实现原理分析
- Android视图SurfaceView的实现原理分析
- Android应用程序UI硬件加速渲染
- 简要介绍和学习计划
- 环境初始化过程分析
- 预加载资源地图集服务（Asset Atlas Service）分析
- Display List构建过程分析
- Display List渲染过程分析
- 动画执行过程分析
- Android应用程序资源管理框架
- Android资源管理框架（Asset Manager）
- Asset Manager 简要介绍和学习计划
- 编译和打包过程分析
- Asset Manager的创建过程分析
- 查找过程分析
- Dalvik虚拟机和ART虚拟机
- Dalvik虚拟机
- Dalvik虚拟机简要介绍和学习计划
- Dalvik虚拟机的启动过程分析
- Dalvik虚拟机的运行过程分析
- Dalvik虚拟机JNI方法的注册过程分析
- Dalvik虚拟机进程和线程的创建过程分析
- Dalvik虚拟机垃圾收集机制简要介绍和学习计划
- Dalvik虚拟机Java堆创建过程分析
- Dalvik虚拟机为新创建对象分配内存的过程分析
- Dalvik虚拟机垃圾收集（GC）过程分析
- ART虚拟机
- Android ART运行时无缝替换Dalvik虚拟机的过程分析
- Android运行时ART简要介绍和学习计划
- Android运行时ART加载OAT文件的过程分析
- Android运行时ART加载类和方法的过程分析
- Android运行时ART执行类方法的过程分析
- ART运行时垃圾收集机制简要介绍和学习计划
- ART运行时Java堆创建过程分析
- ART运行时为新创建对象分配内存的过程分析
- ART运行时垃圾收集（GC）过程分析
- ART运行时Compacting GC简要介绍和学习计划
- ART运行时Compacting GC堆创建过程分析
- ART运行时Compacting GC为新创建对象分配内存的过程分析
- ART运行时Semi-Space（SS）和Generational Semi-Space（GSS）GC执行过程分析
- ART运行时Mark-Compact（ MC）GC执行过程分析
- ART运行时Foreground GC和Background GC切换过程分析
- Android安全机制
- SEAndroid安全机制简要介绍和学习计划
- SEAndroid安全机制框架分析
- SEAndroid安全机制中的文件安全上下文关联分析
- SEAndroid安全机制中的进程安全上下文关联分析
- SEAndroid安全机制对Android属性访问的保护分析
- SEAndroid安全机制对Binder IPC的保护分析
- 从NDK在非Root手机上的调试原理探讨Android的安全机制
- APK防反编译
- Android视频硬解稳定性问题探讨和处理
- Android系统的智能指针（轻量级指针、强指针和弱指针）的实现原理分析
- Android应用程序安装过程源代码分析
- Android应用程序启动过程源代码分析
- 四大组件源代码分析
- Activity
- Android应用程序的Activity启动过程简要介绍和学习计划
- Android应用程序内部启动Activity过程（startActivity）的源代码分析
- 解开Android应用程序组件Activity的"singleTask"之谜
- Android应用程序在新的进程中启动新的Activity的方法和过程分析
- Service
- Android应用程序绑定服务（bindService）的过程源代码分析
- ContentProvider
- Android应用程序组件Content Provider简要介绍和学习计划
- Android应用程序组件Content Provider应用实例
- Android应用程序组件Content Provider的启动过程源代码分析
- Android应用程序组件Content Provider在应用程序之间共享数据的原理分析
- Android应用程序组件Content Provider的共享数据更新通知机制分析
- BroadcastReceiver
- Android系统中的广播（Broadcast）机制简要介绍和学习计划
- Android应用程序注册广播接收器（registerReceiver）的过程分析
- Android应用程序发送广播（sendBroadcast）的过程分析