ART运行时Foreground GC和Background GC切换过程分析

更新时间:2015-05-07 10:38:42点击次数:757次

通过前面一系列文章的学习,我们知道了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启动过程简要介绍和学习计划这个系列的文章可以知道,应用程序组件是通过ActivityManagerService进行启动的。例如,当我们从Launcher启动一个应用程序时,实际的是在这个应用程序中Action和Category分别被配置为MAIN和LAUNCHER的Activity。这个Activity最终由ActivityManagerService通知其所在的进程进行启动工作的,也就是通过ApplicationThread类的成员函数scheduleLaunchActivity开始执行启动工作的。其它类型的组件的启动过程也是类似的,这里我们仅以Activity的启动过程作为示例,来说明ART运行时如何知道要进行Foreground GC和Background GC切换的。


ApplicationThread类的成员函数scheduleLaunchActivity的实现如下所示:


[java] view plaincopy

1public final class ActivityThread {    

2    ......    

3    

4    private class ApplicationThread extends ApplicationThreadNative {    

5        ......    

6   

7        public final void scheduleLaunchActivity(Intent intent, IBinder token, int ident,    

8                ActivityInfo info, Configuration curConfig, CompatibilityInfo compatInfo,    

9                IVoiceInteractor voiceInteractor, int procState, Bundle state,    

10                PersistableBundle persistentState, List<ResultInfo> pendingResults,    

11                List<Intent> pendingNewIntents, boolean notResumed, boolean isForward,    

12                ProfilerInfo profilerInfo) {    

13    

14            updateProcessState(procState, false);    

15    

16            ActivityClientRecord r = new ActivityClientRecord();    

17    

18            r.token = token;    

19            r.ident = ident;    

20            r.intent = intent;    

21            r.voiceInteractor = voiceInteractor;    

22            r.activityInfo = info;    

23            r.compatInfo = compatInfo;    

24            r.state = state;    

25            r.persistentState = persistentState;    

26    

27            r.pendingResults = pendingResults;    

28            r.pendingIntents = pendingNewIntents;    

29    

30            r.startsNotResumed = notResumed;    

31            r.isForward = isForward;    

32    

33            r.profilerInfo = profilerInfo;    

34    

35            updatePendingConfiguration(curConfig);    

36   

37            sendMessage(H.LAUNCH_ACTIVITY, r);    

38        }    

39    

40        ......    

41    }    

52    

43    ......    

44}    

这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。


ApplicationThread类的成员函数scheduleLaunchActivity首先是调用另外一个成员函数updateProcessState更新进程的当前状态,接着再将其余参数封装在一个ActivityClientRecord对象中,并且将这个ActivityClientRecord对象通过一个H.LAUNCH_ACTIVITY消息传递给应用程序主线程处理。应用程序主线程处理对这个消息的处理就是启动指定的Activity,这个过程可以参考前面Android应用程序的Activity启动过程简要介绍和学习计划这个系列的文章。ApplicationThread类的成员函数scheduleLaunchActivity还调用了另外一个成员函数updatePendingConfiguration将参数curConfig描述的系统当前配置信息保存下来待后面处理。


我们主要关注ApplicationThread类的成员函数updateProcessState,因为它涉及到进程状态的更新,它的实现如下所示:


[java] view plaincopy

1 public final class ActivityThread {    

2     ......    

3     

4     private class ApplicationThread extends ApplicationThreadNative {    

5        ......    

6    

7        public void updateProcessState(int processState, boolean fromIpc) {    

8            synchronized (this) {    

9                if (mLastProcessState != processState) {    

10                    mLastProcessState = processState;    

11                    // Update Dalvik state based on ActivityManager.PROCESS_STATE_* constants.    

12                    final int DALVIK_PROCESS_STATE_JANK_PERCEPTIBLE = 0;    

13                    final int DALVIK_PROCESS_STATE_JANK_IMPERCEPTIBLE = 1;    

14                    int dalvikProcessState = DALVIK_PROCESS_STATE_JANK_IMPERCEPTIBLE;    

15                    // TODO: Tune this since things like gmail sync are important background but not jank perceptible.    

16                    if (processState <= ActivityManager.PROCESS_STATE_IMPORTANT_FOREGROUND) {    

17                        dalvikProcessState = DALVIK_PROCESS_STATE_JANK_PERCEPTIBLE;    

18                    }    

19                    VMRuntime.getRuntime().updateProcessState(dalvikProcessState);    

20                    ......    

21                }    

22            }    

23        }    

24    

25        ......    

26    }    

27    

28    ......    

29}    

这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。


ApplicationThread类的成员变量mLastProcessState描述的是进程上一次的状态,而参数processState描述的是进程当前的状态。当这两者的值不一致时,就表明进程的状态发生了变化,这时候就需要调用VMRuntime类的成员函数updateProcessState通知ART运行时,以便ART运行时可以在Foreground GC和Background GC之间切换。

ActivityManagerService一共定义了14种进程状态,如下所示:


[java] view plaincopy

1public class ActivityManager {    

2    ......    

3    

4    /** @hide Process is a persistent system process. */    

5    public static final int PROCESS_STATE_PERSISTENT = 0;    

6    

7    /** @hide Process is a persistent system process and is doing UI. */    

8    public static final int PROCESS_STATE_PERSISTENT_UI = 1;    

9    

10    /** @hide Process is hosting the current top activities.  Note that this covers  

11     * all activities that are visible to the user. */    

12    public static final int PROCESS_STATE_TOP = 2;    

13    

14    /** @hide Process is important to the user, and something they are aware of. */    

15    public static final int PROCESS_STATE_IMPORTANT_FOREGROUND = 3;    

16   

17    /** @hide Process is important to the user, but not something they are aware of. */    

18    public static final int PROCESS_STATE_IMPORTANT_BACKGROUND = 4;    

19    

20    /** @hide Process is in the background running a backup/restore operation. */    

21    public static final int PROCESS_STATE_BACKUP = 5;    

22    

23    /** @hide Process is in the background, but it can't restore its state so we want  

24     * to try to avoid killing it. */    

25    public static final int PROCESS_STATE_HEAVY_WEIGHT = 6;    

26    

27    /** @hide Process is in the background running a service.  Unlike oom_adj, this level  

28     * is used for both the normal running in background state and the executing  

29     * operations state. */    

30    public static final int PROCESS_STATE_SERVICE = 7;    

31    

32    /** @hide Process is in the background running a receiver.   Note that from the  

33     * perspective of oom_adj receivers run at a higher foreground level, but for our  

34     * prioritization here that is not necessary and putting them below services means  

35     * many fewer changes in some process states as they receive broadcasts. */    

36    public static final int PROCESS_STATE_RECEIVER = 8;    

37    

38    /** @hide Process is in the background but hosts the home activity. */    

39    public static final int PROCESS_STATE_HOME = 9;    

40    

41    /** @hide Process is in the background but hosts the last shown activity. */    

42    public static final int PROCESS_STATE_LAST_ACTIVITY = 10;    

43    

44    /** @hide Process is being cached for later use and contains activities. */    

45    public static final int PROCESS_STATE_CACHED_ACTIVITY = 11;    

46    

47    /** @hide Process is being cached for later use and is a client of another cached  

48     * process that contains activities. */    

49    public static final int PROCESS_STATE_CACHED_ACTIVITY_CLIENT = 12;    

50    

51    /** @hide Process is being cached for later use and is empty. */    

52    public static final int PROCESS_STATE_CACHED_EMPTY = 13;    

53    

54    ......    

55}    

这些进程状态值定义在文件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直接设置应用程序的状态,它的实现如下所示:


[java] view plaincopy

1public final class ActivityThread {    

2    ......    

3    

4    private class ApplicationThread extends ApplicationThreadNative {    

5        ......    

6    

7        public void setProcessState(int state) {    

8            updateProcessState(state, true);    

9        }    

10    

11        ......    

12    }    

13    

14    ......    

15}    

这个函数定义在文件frameworks/base/core/java/android/app/ActivityThread.java中。


ApplicationThread类实现的Binder接口setProcessState也是通过上面分析的成员函数updateProcessState来通知ART运行时进程状态发生了改变的。不过这时候进程的状态就有可能是从前面进程变为后台进程,例如当运行在该进程的Activity组件处理Stop状态时。


接下来我们继续分析VMRuntime类的成员函数updateProcessState的实现,以便了解ART运行时执行Foreground GC和Background GC切换的过程,如下所示:


[java] view plaincopy

1public final class VMRuntime {    

2    ......    

3    

4    /**  

5     * Let the heap know of the new process state. This can change allocation and garbage collection  

6     * behavior regarding trimming and compaction.  

7     */    

8    public native void updateProcessState(int state);    

9    

10    ......    

11}    

这个函数定义在文件libcore/libart/src/main/java/dalvik/system/VMRuntime.java中。


VMRuntime类的成员函数updateProcessState是一个Native函数,它由C++层的函数VMRuntime_updateProcessState实现,如下所示:


[cpp] view plaincopy

1static void VMRuntime_updateProcessState(JNIEnv* env, jobject, jint process_state) {    

2 Runtime::Current()->GetHeap()->UpdateProcessState(static_cast<gc::ProcessState>(process_state));    

3  ......    

4}    

这个函数定义在文件art/runtime/native/dalvik_system_VMRuntime.cc中。


函数VMRuntime_updateProcessState主要是调用了Heap类的成员函数UpdateProcessState来通知ART运行时切换Foreground GC和Background GC,后者的实现如下所示:


[cpp] view plaincopy

1void Heap::UpdateProcessState(ProcessState process_state) {    

2  if (process_state_ != process_state) {    

3    process_state_ = process_state;    

4    ......    

5    if (process_state_ == kProcessStateJankPerceptible) {    

6      // Transition back to foreground right away to prevent jank.    

7      RequestCollectorTransition(foreground_collector_type_, 0);    

8    } else {    

9      // Don't delay for debug builds since we may want to stress test the GC.    

10      // If background_collector_type_ is kCollectorTypeHomogeneousSpaceCompact then we have    

11     // special handling which does a homogenous space compaction once but then doesn't transition    

12      // the collector.    

13      RequestCollectorTransition(background_collector_type_,    

14                                 kIsDebugBuild ? 0 : kCollectorTransitionWait);    

15    }    

16  }    

17}    

这个函数定义在文件art/runtime/gc/heap.cc中。


Heap类的成员变量prcess_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的实现如下所示:


[cpp] view plaincopy

1void Heap::RequestCollectorTransition(CollectorType desired_collector_type, uint64_t delta_time) {    

2  Thread* self = Thread::Current();    

3  {    

4    MutexLock mu(self, *heap_trim_request_lock_);    

5    if (desired_collector_type_ == desired_collector_type) {    

6      return;    

7    }    

8    heap_transition_or_trim_target_time_ =    

9        std::max(heap_transition_or_trim_target_time_, NanoTime() + delta_time);    

10    desired_collector_type_ = desired_collector_type;    

11  }    

12  SignalHeapTrimDaemon(self);    

13}    

这个函数定义在文件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的实现如下所示:


[cpp] view plaincopy

1void Heap::SignalHeapTrimDaemon(Thread* self) {    

2  JNIEnv* env = self->GetJniEnv();    

3  DCHECK(WellKnownClasses::java_lang_Daemons != nullptr);    

4  DCHECK(WellKnownClasses::java_lang_Daemons_requestHeapTrim != nullptr);    

5  env->CallStaticVoidMethod(WellKnownClasses::java_lang_Daemons,    

6                            WellKnownClasses::java_lang_Daemons_requestHeapTrim);    

7  CHECK(!env->ExceptionCheck());    

8}    

这个函数定义在文件art/runtime/gc/heap.cc中。


Heap类的成员函数RequestCollectorTransition通过JNI接口调用了Daemons类的静态成员函数requestHeapTrim请求执行一次GC切换操作。


Daemons类的静态成员函数requestHeapTrim的实现如下所示:


[java] view plaincopy

1public final class Daemons {    

2    ......    

3    

4    public static void requestHeapTrim() {    

5        synchronized (HeapTrimmerDaemon.INSTANCE) {    

6            HeapTrimmerDaemon.INSTANCE.notify();    

7        }    

8    }    

9   

10    ......    

11}    

这个函数定义在文件libcore/libart/src/main/java/java/lang/Daemons.java中。


在前面 ART运行时垃圾收集(GC)过程分析一文中提到,Java层的java.lang.Daemons类在加载的时候,会启动五个与堆或者GC相关的守护线程,其中一个守护线程就是HeapTrimmerDaemon,这里通过调用它的成员函数notify来唤醒它。


HeapTrimmerDaemon原先被Block在成员函数run中,当它被唤醒之后 ,就会继续执行它的成员函数run,如下所示:


[java] view plaincopy

1public final class Daemons {    

2    ......    

3    

4    private static class HeapTrimmerDaemon extends Daemon {    

5        private static final HeapTrimmerDaemon INSTANCE = new HeapTrimmerDaemon();    

6   

7        @Override public void run() {    

8            while (isRunning()) {    

9                try {    

10                    synchronized (this) {    

11                        wait();    

12                    }    

13                    VMRuntime.getRuntime().trimHeap();    

14                } catch (InterruptedException ignored) {    

15                }    

16            }    

17        }    

18    }    

19    

20    ......    

21}    

这个函数定义在文件libcore/libart/src/main/java/java/lang/Daemons.java中。


从这里就可以看到,HeapTrimmerDaemon被唤醒之后,就会调用VMRuntime类的成员函数trimHeap来执行GC切换操作。


VMRuntime类的成员函数trimHeap是一个Native函数,由C++层的函数VMRuntime_trimHeap实现,如下所示:


[cpp] view plaincopy

1static void VMRuntime_trimHeap(JNIEnv*, jobject) {    

2  Runtime::Current()->GetHeap()->DoPendingTransitionOrTrim();    

3}    

这个函数定义在文件art/runtime/native/dalvik_system_VMRuntime.cc 。


函数VMRuntime_trimHeap又是通过调用Heap类的成员函数DoPendingTransitionOrTrim来执行GC切换操作的,如下所示:


[cpp] view plaincopy

1void Heap::DoPendingTransitionOrTrim() {    

2  Thread* self = Thread::Current();    

3  CollectorType desired_collector_type;    

4  // Wait until we reach the desired transition time.    

5  while (true) {    

6    uint64_t wait_time;    

7    {    

8      MutexLock mu(self, *heap_trim_request_lock_);    

9      desired_collector_type = desired_collector_type_;    

10      uint64_t current_time = NanoTime();    

11      if (current_time >= heap_transition_or_trim_target_time_) {    

12        break;    

13      }    

14      wait_time = heap_transition_or_trim_target_time_ - current_time;    

15    }    

16    ScopedThreadStateChange tsc(self, kSleeping);    

17    usleep(wait_time / 1000);  // Usleep takes microseconds.    

18  }    

19  // Launch homogeneous space compaction if it is desired.    

20  if (desired_collector_type == kCollectorTypeHomogeneousSpaceCompact) {    

21    if (!CareAboutPauseTimes()) {    

22      PerformHomogeneousSpaceCompact();    

23    }    

24    // No need to Trim(). Homogeneous space compaction may free more virtual and physical memory.    

25    desired_collector_type = collector_type_;    

26    return;    

27  }    

28  // Transition the collector if the desired collector type is not the same as the current    

29  // collector type.    

30  TransitionCollector(desired_collector_type);    

31  ......    

32  // Do a heap trim if it is needed.    

33  Trim();    

34}    

这个函数定义在文件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为新创建对象分配内存的过程分析一文。


Heap类的成员函数CareAboutPauseTimes实际上是判断进程的当前状态是否是用户可感知的,即是否等于kProcessStateJankPerceptible。如果是的话,就说明它在乎GC执行时带来的暂停时间。它的实现如下所示:


[cpp] view plaincopy

1class Heap {    

2 public:    

3  ......    

4    

5  // Returns true if we currently care about pause times.    

6  bool CareAboutPauseTimes() const {    

7    return process_state_ == kProcessStateJankPerceptible;    

8  }    

9 ......    

10};    

这个函数定义在文件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)过程分析一文。

接下来我们继续分析Heap类的成员函数TransitionCollector的实现,以便了解GC的切换过程,如下所示:


[cpp] view plaincopy

1void Heap::TransitionCollector(CollectorType collector_type) {    

2  if (collector_type == collector_type_) {    

3    return;    

4  }    

5  ......    

6  ThreadList* const tl = runtime->GetThreadList();    

7  ......    

8  // Busy wait until we can GC (StartGC can fail if we have a non-zero    

9  // compacting_gc_disable_count_, this should rarely occurs).    

10  for (;;) {    

11    {    

12      ScopedThreadStateChange tsc(self, kWaitingForGcToComplete);    

13      MutexLock mu(self, *gc_complete_lock_);    

14      // Ensure there is only one GC at a time.    

15      WaitForGcToCompleteLocked(kGcCauseCollectorTransition, self);    

16      // Currently we only need a heap transition if we switch from a moving collector to a    

17      // non-moving one, or visa versa.    

18      const bool copying_transition = IsMovingGc(collector_type_) != IsMovingGc(collector_type);    

19      // If someone else beat us to it and changed the collector before we could, exit.    

20      // This is safe to do before the suspend all since we set the collector_type_running_ before    

21      // we exit the loop. If another thread attempts to do the heap transition before we exit,    

22      // then it would get blocked on WaitForGcToCompleteLocked.    

23      if (collector_type == collector_type_) {    

24        return;    

25      }    

26      // GC can be disabled if someone has a used GetPrimitiveArrayCritical but not yet released.    

27      if (!copying_transition || disable_moving_gc_count_ == 0) {    

28        // TODO: Not hard code in semi-space collector?    

29        collector_type_running_ = copying_transition ? kCollectorTypeSS : collector_type;    

30        break;    

31      }    

32    }    

33    usleep(1000);    

34  }    

35  tl->SuspendAll();    

36  switch (collector_type) {    

37    case kCollectorTypeSS: {    

38      if (!IsMovingGc(collector_type_)) {    

39        // Create the bump pointer space from the backup space.    

40        ......    

41        std::unique_ptr<MemMap> mem_map(main_space_backup_->ReleaseMemMap());    

42        // We are transitioning from non moving GC -> moving GC, since we copied from the bump    

43        // pointer space last transition it will be protected.    

44        .....    

45        mem_map->Protect(PROT_READ | PROT_WRITE);    

46        bump_pointer_space_ = space::BumpPointerSpace::CreateFromMemMap("Bump pointer space",    

47                                                                        mem_map.release());    

48        AddSpace(bump_pointer_space_);    

49        Compact(bump_pointer_space_, main_space_, kGcCauseCollectorTransition);    

50        // Use the now empty main space mem map for the bump pointer temp space.    

51        mem_map.reset(main_space_->ReleaseMemMap());    

52        // Unset the pointers just in case.    

53        if (dlmalloc_space_ == main_space_) {    

54          dlmalloc_space_ = nullptr;    

55        } else if (rosalloc_space_ == main_space_) {    

56          rosalloc_space_ = nullptr;    

57        }    

58        // Remove the main space so that we don't try to trim it, this doens't work for debug    

59        // builds since RosAlloc attempts to read the magic number from a protected page.    

60        RemoveSpace(main_space_);    

61        RemoveRememberedSet(main_space_);    

62        delete main_space_;  // Delete the space since it has been removed.    

63        main_space_ = nullptr;    

64        RemoveRememberedSet(main_space_backup_.get());    

65        main_space_backup_.reset(nullptr);  // Deletes the space.    

66        temp_space_ = space::BumpPointerSpace::CreateFromMemMap("Bump pointer space 2",    

67                                                                mem_map.release());    

68        AddSpace(temp_space_);    

69      }    

70      break;    

71    }    

72    case kCollectorTypeMS:    

73      // Fall through.    

74    case kCollectorTypeCMS: {    

75      if (IsMovingGc(collector_type_)) {    

76        ......    

77        std::unique_ptr<MemMap> mem_map(temp_space_->ReleaseMemMap());    

78        RemoveSpace(temp_space_);    

79        temp_space_ = nullptr;    

80        mem_map->Protect(PROT_READ | PROT_WRITE);    

81        CreateMainMallocSpace(mem_map.get(), kDefaultInitialSize, mem_map->Size(),    

82                              mem_map->Size());    

83        mem_map.release();    

84        // Compact to the main space from the bump pointer space, don't need to swap semispaces.    

85        AddSpace(main_space_);    

86        Compact(main_space_, bump_pointer_space_, kGcCauseCollectorTransition);    

87        mem_map.reset(bump_pointer_space_->ReleaseMemMap());    

88        RemoveSpace(bump_pointer_space_);    

89        bump_pointer_space_ = nullptr;    

90        const char* name = kUseRosAlloc ? kRosAllocSpaceName[1] : kDlMallocSpaceName[1];    

91        ......    

92        main_space_backup_.reset(CreateMallocSpaceFromMemMap(mem_map.get(), kDefaultInitialSize,    

93                                                             mem_map->Size(), mem_map->Size(),    

94                                                             name, true));    

95        ......    

96        mem_map.release();    

97      }    

98      break;    

99    }    

100    default: {    

101      ......    

102      break;    

103    }    

104  ChangeCollector(collector_type);    

105  tl->ResumeAll();    

106  ......    

107}    

这个函数定义在文件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为新创建对象分配内存的过程分析一文已经分析过了,它主要通过执行一次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堆创建过程分析一文可以知道,当原来的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堆创建过程分析一文可以知道,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堆创建过程分析一文可以知道,当原来的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为新创建对象分配内存的过程分析一文。


至此,ART运行时Foreground GC和Background GC的切换过程分析就分析完成了,ART运行时引进的Compacting GC的学习计划也已完成,重新学习可以参考ART运行时Compacting GC简要介绍和学习计划一文。


  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息
  • 项目经理 点击这里给我发消息